Requirements Desk

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

With no annotations, the description carries the full behavioral burden. It does disclose that results carry period, form and accession number, which is useful return context, but it says nothing about read-only semantics, defaults, multi-period returns, behavior when both cik and ticker are supplied or neither is, or error conditions.

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 front-loaded sentence with no filler and no repetition of the tool name. It is dense but every clause (concept, filer, period, form, accession) carries information.

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?

Four undocumented parameters, no annotations, and no output schema leave the description too thin for an agent to call this correctly. The most consequential decision – choosing a taxonomy and resolving the filer identifier – is left entirely to inference.

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 0% across four parameters, so the description must compensate and largely does not. "One concept" and "one SEC filer" loosely map to concept and cik/ticker, but the taxonomy enum (us-gaap, ifrs-full, dei) – which determines the concept's namespace – and the cik-versus-ticker relationship are never explained.

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?

"Reported XBRL values of one concept for one SEC filer" names a specific resource (XBRL financial facts) and bounds the scope (single concept, single filer). No sibling tool in the list touches financial statements, so the tool is trivially distinguishable, but the description itself does not explicitly contrast with alternatives.

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?

There is no when-to-use guidance, no statement of preconditions, and no mention of alternatives such as entity_lookup for resolving a filer. The phrase "one concept for one SEC filer" hints that callers must narrow to a single concept, but no explicit usage rule is given.

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?

No annotations are supplied, so the description carries the full load; it does disclose the shape of the response (request handling, returned data, scope/limits, fields, operations), which is valuable and implies a read-only lookup. It says nothing about failure behavior for unknown slugs, authentication, or whether the 'operations' list implies anything actionable.

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 compact sentence with no filler, though it is a comma-separated inventory rather than being front-loaded with a clear statement of what the tool does.

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?

With no output schema and no annotations, the description does a reasonable job of previewing return contents, but it leaves the sole input undocumented and the proposition-versus-service terminology unresolved, which is a real gap for a one-parameter lookup 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?

There is one parameter, slug, with 0% schema description coverage, and the description never explains what a slug is, where to obtain one, or its format/limits (maxLength 80 goes unmentioned). The reference to 'request fields' concerns the described service, not the input parameter, so it does not compensate.

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 enumerates what the tool returns (request behavior, outputs, scope and limits, fields, operations) which implies a detail-lookup for a single item, but it never states a verb or resource explicitly and shifts vocabulary from 'proposition' in the name to 'service' in the text. An agent can infer it is the detail counterpart to list_propositions, but only by guessing.

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?

No when-to-use guidance, no prerequisites, and no named alternative such as list_propositions for enumeration versus this tool for drill-down. The agent must infer the selection rule from the tool name alone.

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 it does disclose two genuinely useful traits: the call is paid ($0.02 via x402 over HTTP) and the tool itself returns calling instructions. However, it omits what happens when no identifier is supplied, whether a payment/x402 handshake is required before any result, error behavior, and whether results are cached or live.

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 short sentences with no filler, and the data-domain statement is front-loaded ahead of the payment caveat. The second sentence is terse to the point of ambiguity rather than verbose.

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?

A four-parameter tool with no annotations and no output schema needs the description to explain identifier requirements and return shape; instead it leaves both unstated and adds a confusing claim that the tool returns how to call the endpoint. The payment model is the only completeness win.

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 0% across four parameters, so the description must compensate and does not: cik, lei, name, and ticker are never mentioned, nor is the critical fact that all four are optional (so presumably at least one identifier must be supplied, or matching/priority rules apply). It adds no meaning beyond the bare property names.

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 the resources (LEI records, SEC EDGAR registration) and the domain object (a company), but the second sentence muddies it: 'this tool returns how to call it' implies the tool is a discovery stub returning invocation instructions for a paid HTTP endpoint rather than the entity data itself. An agent cannot be certain whether a call yields records or metadata about how to obtain them.

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?

No guidance on when to choose this over siblings such as company_financial_facts, nor any exclusions or prerequisites. The only implicit signal is that it is entity-identity data rather than financial or sanctions data, which the agent must infer from the noun phrase alone.

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?

No annotations are supplied, so the description carries the entire behavioral burden. It does add two useful facts beyond the schema: only public pages are readable and robots.txt is honoured, meaning a request can be legitimately refused. However, it says nothing about rate limits, whether JavaScript-rendered content is captured, content truncation, or how failures surface — significant gaps for a fetch tool with zero annotation coverage.

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 lean sentences with the returned payload front-loaded and the robots.txt caveat second. Nothing is redundant. It is arguably terse to a fault — the second sentence is a fragment that could have carried more behavioral detail at no length cost.

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?

The tool is simple (one parameter, no nested objects, no output schema), and the description covers scope, payload and one hard constraint. Given no annotations and no output schema, an agent still lacks information about failure modes, JavaScript rendering and size limits, which are the practical questions when scraping a page.

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 0% for the single required 'url' parameter, so the description must compensate. It constrains the target to a public web page, which usefully rules out intranet/authenticated URLs, but gives no format guidance and no hint of the 2000-character cap or how redirects are treated. Partial compensation only.

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 names a specific verb (read) and resource (one public web page) and enumerates exactly what is returned: title, headings, text, links and JSON-LD. The scope word 'one' and 'public' bound the operation. Sibling tools are unrelated domains (financial facts, sanctions, propositions), so no sibling differentiation is required, though none is offered.

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 verb 'read' and the word 'public' — an agent can infer this is for fetching a single page's content rather than bulk crawling or authenticated pages. There is no explicit when-to-use statement, no statement of alternatives (e.g., any search or browsing sibling), and no note on what to do when a page cannot be fetched.

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 it does disclose two useful behavioral facts: the hard cap of 25 results and the upstream data source. It omits sorting/recency semantics, whether the cap silently truncates a larger result set, and what a typical record contains, all of which matter for a read tool with no output schema.

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 front-loaded sentence with zero filler; the result cap and source sit at the edges while the filters occupy the core. Nothing is wasted or buried.

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 four-filter query tool with no annotations and no output schema, the definition is thin: it never describes returned fields, default behavior with zero filters, sort order, or how multiple filters combine. An agent could invoke it but could not predict or validate what it receives.

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 0%, so the description has to compensate, and it does list all four parameter names mapped to their meaning. However it adds no format detail beyond the schema's own maxLength constraints — nothing on state being a two-letter code, fiscal year versus calendar year, or NAICS prefix matching versus exact code.

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 names a concrete resource (US federal contract awards), the four filter dimensions, and the source system (USAspending.gov), so an agent can tell exactly what data comes back. It lacks an explicit verb and never says whether results are a filtered list or a ranked set, but the resource is unambiguous and shares no overlap with any sibling tool.

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?

There is no guidance on when to call this versus anything else, no prerequisites, and no note that all four parameters are optional or what happens when none are supplied. The agent must infer that omitting filters yields an arbitrary 25 awards, which is a meaningful gap.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that results include a one-line summary, but says nothing about ordering, pagination, scope limits, permissions, or what "working operations" versus "requirements recorded" actually means.

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 a single sentence with the list action front-loaded, so it is compact. However, the colon introduces a confusing appositive that muddles rather than clarifies the resource being listed.

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 list tool with no output schema and no annotations, the description should clearly define what a proposition is and what the returned one-line summaries contain. The current wording leaves the core resource ambiguous and provides no sense of result size or scope.

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 is 4. The description does not need to explain parameter semantics.

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 says "List every service," which is a clear verb but names a resource ("service") that never appears in the tool name "list_propositions." The phrase "working operations and the requirements recorded" gestures at propositions but does not define them, so an agent cannot confidently tell what is being listed.

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?

There is no explicit guidance on when to use this tool versus the sibling describe_proposition or entity_lookup. "List every service" implies a broad enumeration use case, but the agent must infer that from an ambiguous sentence.

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 it does disclose one genuinely valuable behavioral trait: results are screening leads requiring adjudication, not definitive matches. It says nothing about whether this calls an external service, latency, rate limits, or what the response contains.

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 short sentences, purpose front-loaded, with the important cautionary caveat second. No filler and no redundancy with 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?

For a simple two-parameter tool this covers the essentials of what it does and how to treat matches, but with no output schema there is no description of what a screening response looks like (candidate list, scores, alias hits). Combined with the fully undocumented min_score, an agent cannot call this tool confidently.

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 0%, so the description must explain both parameters and explains neither. The 'name' parameter is at least implied by 'screen a name', but 'min_score' (0.5-1.0 fuzzy threshold) — the parameter most likely to be misused — is completely undocumented anywhere.

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 (screen) and resource (a name against the OFAC SDN list and aliases), which is far more informative than the bare tool name. It does not, however, distinguish itself from the similar-sounding sibling 'entity_lookup', so an agent must still guess which to pick.

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 only guidance offered is interpretive ('a match is a lead for review, not a determination'), which tells the agent how to read output but not when to invoke this tool versus entity_lookup or the other siblings. No prerequisites, no exclusions, no alternative routing.

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 disclose meaningful behavior: nothing is arranged on the user's behalf (no fulfillment side effect) and a receipt is returned listing uncovered fields. It omits idempotency, whether submissions are reviewed, retry/rate behavior, and whether contact storage is optional — details that matter for a write 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?

Two dense sentences, front-loaded with the core action and the fallback slug rule. Slightly clipped phrasing ("Nothing is arranged on your behalf") reads as compact rather than padded.

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 tool with 10 parameters, nested objects, no output schema, and no annotations, the description is thin. It never explains the receipt's structure despite referencing it, nor does it cover the majority of optional fields, leaving an agent guessing at how to build a well-formed submission.

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 only 40% across 10 parameters, so the description must compensate. It clarifies the sentinel value for `slug` and hints that `specifications`/`requested_fields` relate to fields no listed service covers, but leaves `action`, `budget`, `timing`, `quantity`, and `geography` entirely unexplained in both schema and description.

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?

"Record a requirement" is a specific verb+resource, and the description states scope (any service) plus the sentinel-slug fallback, which no sibling tool offers. It is not differentiated from the sibling tools by name, but none of them overlap functionally, so an agent can still place 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?

There is an implied routing rule: use slug "anything-else" when no listed service covers the need. However, it never says how to obtain a valid service slug (e.g., via entity_lookup or a listing call), nor does it state any prerequisite or exclusion beyond that one branch.

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