x402 SEC EDGAR Lookup

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses the upstream data source, public-domain licensing, no API key with x402 payment ($0.003/call), that failed lookups and upstream errors are free, and that the freshest of several standard us-gaap tags is chosen with an ifrs-full fallback. It stops short of rate limits or partial-failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, front-loaded with what the tool returns before the return-shape and billing details. Every sentence contributes something an agent needs, given there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, no-output-schema tool the description covers data source, return fields, tag selection and billing sufficiently to call it correctly. Minor gaps are error handling for invalid tickers/CIKs and whether non-US IFRS filers are fully supported.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so company, metrics, annual_periods and quarterly_periods are already documented in the schema; the description only reiterates that metrics is an optional subset. Baseline 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (key financials from a company's XBRL filings via SEC companyconcept) and enumerates the exact metric set returned, so an agent can immediately tell this apart from filing_text, recent_filings and company_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the metric list; there is no explicit statement of when to prefer this over company_lookup or filing_text, and no noted limitations beyond the charging caveat. The 'Optional metrics subset' phrase hints at narrowing scope but leaves the choice to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full burden, and it does most of it: it names the data source (SEC EDGAR public APIs, data.sec.gov), states the public-domain and no-API-key conditions, discloses the $0.001 USDC x402 charge with the important carve-out that not-found and upstream errors are not billed, and describes the ambiguity behavior of returning extra name matches. It omits rate limits, latency and the exact result shape when nothing is found, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the resolving action and then the returned fields, followed by source, licensing, error-billing and price facts in terse order. The field enumeration is dense but every item is a return-value fact an agent cannot get elsewhere given there is no output schema, so it earns its place; only the sentence length hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description must describe both behavior and returns, and it does so thoroughly: every returned field is listed, ambiguity (multiple name matches) is addressed, and cost plus error-billing semantics are spelled out. What remains uncovered is operational detail such as rate limits, timeout behavior and whether results are cached, which is minor for a read-only lookup but not nothing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (query, limit) are already documented with accepted formats and a 1-10 range, making a baseline 3 appropriate. The description corroborates the accepted identifier formats and adds a hint that the response can carry 'up to 9 other name matches', which implicitly relates to the limit default of 5, but it adds no new format or defaulting detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The definition opens with a precise verb-plus-resource statement ('Resolve a ticker, CIK or company name to the SEC registrant') and enumerates the returned identity fields, so an agent can tell this is an identity-resolution endpoint rather than a facts or filings endpoint. It never names the sibling tools (company_facts, recent_filings) or states how it differs from them, which is what keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the accepted identifier types make it clear this is the entry point for a symbol or entity name, but there is no explicit 'use this when' guidance and no exclusion pointing to a sibling when the caller actually wants financial facts or filing lists. The payment and error-policy notes are useful context but are not routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses text processing (HTML/iXBRL stripped, tables tab-separated), truncation and paging behavior via max_chars/offset, the data source, and that errors are not charged. It omits details on the x402 payment flow mechanics and rate limits, leaving modest gaps for a paid mutation-free read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph that front-loads the purpose and then layers output, parameters, data source, and pricing. It is mostly efficient, though it repeats schema defaults like max_chars values and offset defaults, which are already documented in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values, and it does so thoroughly: form, filing date, company, total_chars, a text window, and the list of all documents. Combined with error-charge policy and data source, an agent has everything needed to call and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the offset/next_offset paging relationship, the default primary-document behavior of the document parameter, and the rationale for company (needed when a filing agent submitted the filing), which goes beyond the schema's field-level text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Fetch one document of an SEC filing by accession number and return clean plain text'. It further scopes the tool by explaining the default (primary document) versus exhibits, which distinguishes it clearly from sibling tools like recent_filings and company_facts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context, including when to target an exhibit (EX-99.1 earnings release) and when to pass the company parameter (filing agent submissions). It does not explicitly name alternatives or state exclusions relative to siblings, but the context is sufficiently clear for correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it delivers by disclosing the return contents (status, version, tool prices, network, x402 endpoints) and the cost ('Free'). It omits any statement about side effects or auth, but for an inherently read-only diagnostic that is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core purpose ('Free health check') front-loaded and the returned fields listed immediately after. No filler or redundant restatement of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey the return surface, and it does so by naming the key returned fields. The enumeration is somewhat terse ('network', 'the plain-HTTP x402 endpoints') and doesn't detail response shape, but it is adequate for a parameterless health endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema has nothing to document. The baseline for a 0-parameter tool is 4, and nothing in the description misrepresents or requires parameter explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific function ('Free health check') and enumerates what it returns (service status, version, tool prices, network, x402 endpoints), so the agent knows exactly what this endpoint provides. It does not differentiate itself from the sibling 'ping', which could plausibly serve a similar connectivity-verification role, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Free health check' implies a diagnostic use case and the 'Free' flag hints at a no-cost call, giving implied usage guidance. However, it offers no explicit when-to-use condition, no exclusions, and no mention of how it relates to the sibling 'ping' as an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that the call is paid, the exact cost ($0.001 USDC), the payment mechanism (x402), and the return payload (ok plus timestamp). It stops short of describing failure modes, e.g. what the agent sees if payment is rejected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero filler; purpose comes first, usage and cost follow. Every sentence carries information an agent needs before calling a paid endpoint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema or annotations, the description supplies the essentials: purpose, return values, and the payment precondition. Minor gaps (timestamp format, error behavior on failed payment) are acceptable at this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond what the empty schema already conveys, and it adds no misleading parameter language.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: a paid connectivity test that returns 'ok' and a server timestamp, which is more than a tautology. It does not, however, distinguish itself from the sibling 'health' tool, which an agent will almost certainly consider alongside it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering context: use it to verify the x402 payment flow end to end. It omits any when-not-to-use guidance, notably that a free alternative (health) exists for plain liveness checks, so the agent must infer that distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the default amendment behavior, result cap, EDGAR history depth, data source, no-API-key access, error non-charging, and the $0.002 USDC x402 cost per call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and returned fields, and every sentence adds relevant information. It is dense and somewhat run-on, but there is little wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description enumerates the returned fields and covers filtering, limits, history scope, data source, cost, and error charging. That is enough for an agent to understand and call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters. The description adds useful examples for forms and clarifies the amendment default, but it does not add much beyond the schema and omits company identifier formats that are present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: list a company's SEC filings, newest first, with a detailed set of returned fields. It is clearly distinct in substance from company facts or filing text, but it does not explicitly name or route against the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the clear listing purpose and by the filter options for form types and date range. However, there is no explicit guidance on when to use this versus company_facts, company_lookup, or filing_text, and no when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.