Skip to main content
Build a filing-research workflow that another person can audit: the question, exact source retrieved, fields used in the answer, and any point where it stopped. A sparse response or ranked result is not a conclusion.

​
Define one job

Start with one issuer, one filing family, one date or latest-filing rule, and one output artifact. For example: retrieve NVIDIA’s latest 10-K, read Item 1A, and produce a five-bullet risk brief with the filing identity.
Retain accessionNumber, form, filingDate, filingUrl, and requestId when returned. Keep route-provided provenance, freshness, warnings, and trace fields rather than replacing them with a generic confidence score.

​
Put the operating policy in the task

Record the endpoint or tool, arguments, retrieval time, source artifact, and request identifier with the final answer. A filing section supports claims about that section; it does not establish facts outside it.

​
Match the execution surface to the owner

  • Use REST or an SDK when an application owns retries, timeouts, and persistence.
  • Use the CLI for terminal inspection and scripts.
  • Use hosted MCP when an MCP-aware client must discover tools and schemas during a research session.
For MCP, start with tools.search, then inspect the selected input with tools.describe. For REST, use the endpoint reference rather than copying an MCP schema into a service. These surfaces have different contracts and error handling.

​
Keep repeated runs bounded

Before a loop, read GET /v1/billing and GET /v1/limits; use POST /v1/billing/quote for a current estimate. Quotes do not reserve usage. Billing-aware agent runs covers the account boundary and sponsored credential flow.

​
Next action

Write the output schema for one narrow research job, including its required filing identifiers and an explicit insufficient_evidence outcome, before connecting it to a scheduler or chat workflow.