Bosco Labs data

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: output is one compact JSON row per trial with a link to the source record, and there is a per-result price of $0.004 per trial, which matters for an agent deciding how to size maxResults. It does not disclose pagination or rate-limit behavior, keeping it short of 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?

Two tight sentences plus a one-line price note, with the capability and output shape front-loaded before the audience framing. The audience sentence ('Built for AI agents and people in pharma, biotech...') is the weakest part and borders on filler, but the whole thing stays short.

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 14-parameter, no-output-schema tool the description does the heavy lifting on return values — listing the dossier fields and the per-row link — and adds cost. The main gap is the `detail: full` mode, which the schema barely explains and the description never mentions, so an agent cannot judge what the richer payload contains.

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 every one of the 14 parameters is already documented with examples and formats, making 3 the baseline. The description's field list loosely echoes the filter set (phase, status, sponsor, conditions, drugs, dates, countries) but adds no syntax, matching behavior, or interaction rules beyond what the schema provides.

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 resource (ClinicalTrials.gov trials) and two capabilities — searching by criteria ('which trials?') and pulling a per-trial dossier by NCT ID ('where does this trial stand?') — and enumerates the returned fields (status, phase, sponsor, enrollment, dates, countries, outcomes, results-posted flag). It is clearly distinguishable from siblings like drug_safety or sec_filings_feed, though it never names an alternative to contrast with.

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: the phrase 'which trials?' hints at filter-based search and 'where does this trial stand?' hints at single-trial lookup via nctIds, but the description never explicitly says when to use one mode versus the other, nor when this tool is preferred over a sibling such as drug_safety. The only explicit mode reference ('search mode') appears in the schema, not the description.

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?

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the description is free to add the details that matter: per-call pricing ($0.04 per company-year), that every figure carries its source fact for auditing, and that LEI is joined from GLEIF with a null when absent. It stops short of describing pagination, rate limits, or error behavior when a registration number is unknown.

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?

Front-loaded with the core verb and sources, then the returned fields, then the audit/LEI notes and pricing — a sensible order. It is slightly padded by the audience pitch ('for credit checks, KYB, M&A and lead research, and for AI agents'), which is marketing rather than operational guidance.

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, the description usefully lists the financial fields returned and the accompanying LEI fields, and it explains the country-code defaults. For a 7-parameter, zero-required tool it covers what an agent needs, though it omits response shape details such as per-country grouping and behavior on unmatched identifiers.

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 the schema already documents every parameter, including defaults, digit patterns and the maxResults semantics. The description only echoes the identifier types and the 'newest filings' ordering, adding little syntax or meaning beyond the structured fields — baseline 3 applies.

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 ('Get normalized financials of UK, Danish and Norwegian companies') and enumerates the exact data points returned (revenue, gross profit, equity, employees, etc.). It also names the three official registers it reads from, which clearly separates it from the US-focused sibling sec_company_financials and from company_check.

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 concrete lookup modes ('by company number, CVR or organisation number, or get the newest filings') and target scenarios (credit checks, KYB, M&A, lead research). What is missing is explicit exclusion guidance — nothing tells the agent to use sec_company_financials for US companies or company_check for a lighter lookup, even though those siblings exist.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: per-report pricing ($0.03 per company-report) and the guarantee that every value links back to its official source record. It omits what happens on an ambiguous or unmatched company, which is the main remaining 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?

The core answer is front-loaded, which is good, but the body is a single very long run-on sentence with a dense parenthetical country inventory. Every clause is informative, yet the lack of structure makes it harder to scan than it needs to be.

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 read-only lookup with full schema coverage and no output schema, the description covers return content, country-specific depth, sourcing guarantees and cost. The only missing pieces an agent would want are ambiguity/not-found behavior and any pagination or truncation rules for multi-year results.

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 query, country, include and maxYears. The description adds some indirect meaning by mapping country coverage (France/Finland/Estonia industry data, UK directors, Polish KRS, US banks FDIC) and 'last fiscal years' to the relevant parameters. That is helpful framing but not syntax or format 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 description states a specific verb-plus-resource ('who is this company and what are its numbers') and enumerates concrete returned data: legal name, LEI, registration number, status, financials, SEC filings, directors/PSC, KRS entries, FDIC records. It is far more than a restatement of the name. It stops short of naming which sibling to prefer (sec_company_financials, company_accounts, identifier_resolver), so it does not fully differentiate itself.

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?

It gives an audience/context ('research, KYB or due diligence', 'quick, sourced company profile'), which implies when to reach for it. However, it never states when NOT to use it or which sibling covers a narrower need, leaving the agent to infer routing from the sibling list.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the description does not need to restate safety. It does add genuinely new behavior: a cost model ($0.001 per unit, summary=5 units vs job=1) and the shape of the payload (department/location/country breakdowns, remote share, date range, top titles, per-job links). Rate limits and failure behavior for unknown companies remain undisclosed.

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?

Front-loaded with the core question, then inputs, then outputs, then pricing — a sensible order with no redundancy. The clause "for people who want hiring data without scraping LinkedIn or Indeed" is mildly promotional but does convey the data source, so it earns its place marginally.

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 7-parameter tool with no output schema, the description does the heavy lifting of describing what comes back (summary row fields plus job rows with links) and how billing scales with the summary/job split. It does not say what happens when a company cannot be resolved or how complete the job coverage is, which are the remaining gaps for a prospecting agent.

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 every parameter is already documented with examples and matching semantics, making a baseline of 3 appropriate. The description's "Give company names, domains or job board URLs" merely restates the `companies` schema text and says nothing about `keywords`, `departments`, `locations`, `postedSince` or `maxJobsPerCompany` beyond what the schema provides.

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?

Opens with a concrete question the tool answers ("Is a company hiring, for what, where and since when?") and then states both the input form (names, domains, job board URLs) and the output form (per-company summary plus individual job rows with links). This clearly separates it from siblings like company_check or company_accounts, which cover identity/account data rather than open roles.

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?

Use case is stated at audience level ("sales prospecting, recruiting or market research") and the price line implies a cost tradeoff, but there is no explicit when-to-use-this-vs-sibling guidance, e.g. no mention of when to prefer company_check or sec_company_screen instead. The `summaryOnly` note partially covers the internal cheapest-path decision, which keeps this above a 2.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the call is free with no API key, and an unknown tool name does not fail but returns the closest matching names — a fallback behavior an agent must know before interpreting a response.

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 tight sentences with no filler, and the free/no-key note is front-loaded. The core content sentence is a bare noun list rather than a claim about what the tool does, which makes the opening read a little telegraphically, but nothing is wasted.

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, the description carries the return-value burden and discharges it by enumerating the seven kinds of metadata returned. What is missing is positioning relative to the plan/run siblings, which matters for a discovery-style tool in this cluster.

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% and the single parameter is documented as a tool name. The description goes further by showing accepted spellings ('eu_tenders or eu-tenders'), telling the agent name normalization is tolerated, and stating the recovery path for an unknown name — meaning the schema alone does not provide.

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 exactly what the tool returns for one named tool: input schema, example input, example rows, output fields, price per row, caps and sources. That is specific and resource-scoped, though it is written as a sentence fragment without an explicit verb and never contrasts itself with the sibling plan_official_records_query, which an agent could easily confuse with a discovery step.

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?

Use is only implied: 'Free, no key needed' plus a metadata payload suggests calling this to inspect a tool before using it. There is no explicit when-to-use, no mention of when to prefer plan_official_records_query or run_official_records_plan, and no statement of the ordering in the workflow.

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?

Annotations already declare readOnly/idempotent/openWorld, so the description earns credit for adding beyond them: same-evening freshness for the daily list, full history since FY2008, extra fields on history rows (parent company, NAICS/PSC), ticker matching against the SEC company list, and an explicit price of $0.005 per award. It stops short of covering rate limits, auth, or pagination behavior beyond the maxResults cap.

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 core scope and payload are front-loaded in the first sentence, with the agency-switching caveat and pricing following logically. The audience-targeting sentence and the price line are somewhat promotional but carry real selection information, so little is wasted.

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 an 11-parameter, no-output-schema tool, the description covers the returned entities well enough (winner, amount, service, ticker, shares outstanding, plus parent company and NAICS/PSC on history rows) that an agent knows what to expect. The remaining gap is the lack of explicit differentiation from the closely related us_federal_awards sibling.

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 all 11 parameters already document themselves, which sets the baseline at 3. The description adds only marginal meaning, notably that the default scope is the $7.5M floor implied by minAmountUsd and that agencies can be repointed outside DoD; it does not explain how source values 'dailyList' vs 'history' vs 'both' differ in practice.

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 gives a specific verb and resource ('Get every US Department of Defense contract award of $7.5M or more') plus the payload ('who won, how much, which service ... and the winner's US stock ticker'). It does not name the obvious overlapping sibling, us_federal_awards, so the agent gets no explicit signal for how to tell them apart despite the description hinting the same endpoint can span other agencies.

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 through the audience framing ('For defense-sector investors, government sales teams and AI agents') and the note that the history can be switched to any other federal agency 'with one input'. There is no explicit when-to-use versus us_federal_awards, no when-not, and no prerequisites for invoking it.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured context: a source link for every section, per-row list caps, and an explicit price of $0.004 per drug-query. It stops short of describing behavior for unknown or ambiguous drug names.

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 core capability is front-loaded in the first sentence, with cost placed last where it belongs. The clause "Built for AI agents and people in pharma, health tech, pharmacy, compliance and investing" is marketing padding that does not help an agent decide or invoke.

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, the description must enumerate what comes back, and it does: five named sections, each with a source link, plus counts for FAERS reactions and ordering/newest-first conventions for lists. Combined with full schema coverage and read-only annotations, an agent has enough to call this 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 description coverage is 100% and all three parameters are documented in-schema, so baseline is 3. The description reinforces the single-drug-name input and the section grouping that mode selects, but adds no semantics for the non-dossier mode values or for how maxItems interacts with per-section caps beyond what the schema states.

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 concrete capability with named sections: FDA boxed warning and indications, top FAERS adverse reactions with counts, US recalls and shortages, EU authorisation/EPAR and EU shortages, for a single drug name. That is far more specific than the title alone. It does not, however, distinguish itself from the sibling product_recalls, which plausibly overlaps on the recalls portion.

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 "in one call" and the default dossier mode filling all five sections, which suggests using this tool for a combined safety/regulatory snapshot. There is no explicit statement of when to prefer it over product_recalls or when a narrower single-section call is appropriate, and no stated prerequisites or failure conditions.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-derivable context: the upstream register and its operator, what normalization the response performs, and a per-address price of $0.002, which is important cost information before a 50-item batch call. It stops short of disclosing no-match handling or rate limits.

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?

Front-loaded with the core operation, then return shape, then audience, then price — a sensible order with no wasted sentences. The 'Built for AI agents doing real estate, logistics, KYC/KYB…' clause is slightly promotional, but it does carry use-case signal.

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, the description does a fair job sketching the response, and with zero required parameters it should explain what happens when none are supplied and how the optional inputs combine. Those calling-mode and error-behavior gaps are the main missing pieces for a 7-parameter, multi-mode lookup.

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% and all seven parameters are individually documented there, so the baseline is 3. The description corroborates the `include` sections by listing the same return facets (address, building, coordinates), but it adds nothing about the mutual exclusivity or precedence of `addresses` vs `postcode`/`houseNumber` vs `bagIds` — the one semantic point the schema leaves ambiguous.

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 uses a specific verb pair ('checks and geocodes') on a specific resource ('Dutch addresses against the BAG'), names the authoritative source (Kadaster/PDOK), and enumerates the return payload (postcode, BAG ids, WGS84/RD coordinates, building attributes). No sibling tool covers Dutch addresses, so the agent can identify this uniquely without consulting the schema.

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?

It gives audience/use-case context (real estate, logistics, KYC/KYB, insurance, address-list cleaning) but never frames this as a when-to-use against alternatives and never states how to choose between the three input modes (batch `addresses`, `postcode`+`houseNumber`(+range), or `bagIds`). Usage is implied rather than instructed.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context the annotations cannot carry: a per-decision price ($0.005 per `decision`), which matters for how aggressively an agent sets maxResults, plus the fact that includeText truncates text rather than returning it whole. It does not cover error/empty-result behavior or whether search results include total counts.

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 compact sentences plus a one-line price note; the primary capability is front-loaded and the audience note is clearly secondary. The long mid-sentence enumeration of retrievable fields is dense but each item is informative rather than filler.

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 ten optional parameters and no output schema, the description usefully enumerates what a record contains (court, dates, case numbers, legal area, procedure, inhoudsindicatie, appeal/cassation/AG relations, referenced laws, optional full text), compensating for the absent output schema. What remains unaddressed is outcome behavior — empty result sets, pagination limits beyond the 25-result cap, and cost implications of includeText across many records.

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 the schema already documents every parameter in detail, including ECLI multiplicity, date formats, defaults and the includeText/maxTextChars interaction. The description adds little parameter-level meaning beyond restating the filter dimensions, although it does clarify that the keyword search targets title plus inhoudsindicatie. Baseline 3 is appropriate.

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+resource pair ("Look up Dutch court decisions (uitspraken) by ECLI") and immediately states the second mode ("search them by court, legal area, date and keywords"). The explicit Dutch/Rechtspraak jurisdiction and the ECLI identifier distinguish it from siblings like eu_law_lookup and national_law_lookup without needing to name 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?

It clearly establishes the two usage modes — direct ECLI lookup versus filtered search — and enumerates the searchable dimensions, so an agent knows which parameters select which path. It stops short of naming alternatives or stating when to prefer a sibling (e.g. eu_law_lookup for EU instruments, national_law_lookup for non-Dutch jurisdictions), which is the main 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-schema behavior: pricing at $0.05 per 'filing-processed', per-fact-row charging for includeRawFacts, and provenance (every number carries the exact XBRL fact plus a viewer link), which tells the agent results are auditable. It does not disclose result-size or truncation behavior beyond the maxFilings cap.

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?

Front-loaded with the core verb and resource, then metrics, then provenance, then pricing – a sensible priority order. Some filler is present ('so you can audit any value in one click', the audience sentence) that restates rather than informs, but nothing is seriously bloated.

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 read-only, all-optional-parameter query tool with full schema coverage and no output schema. The description compensates for the missing output schema by naming the returned metrics and the fact/record_type structure exposed via includeRawFacts, and it covers pricing. Only gap is fetch limits and result volume, which are partially handled by the maxFilings schema field.

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?

With 100% schema description coverage the baseline is 3, but the description adds cost semantics the schema lacks: includeRawFacts produces one row per tagged fact and is 'charged per fact row', which materially affects how an agent should set that flag. It also reinforces the LEI-first lookup strategy ('the most precise lookup, any country') that the schema only hints at.

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 ('Get normalized key financials from the official ESEF annual reports of European listed companies') and enumerates the lookup keys (LEI, company name, country, fiscal year) plus the metrics returned (revenue, EBIT, EBITDA, net income, EPS, margins, ROE, growth). The geographic scope ('European listed companies') implicitly separates it from the sibling sec_company_financials, so an agent can route without opening either schema.

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 context is implied by the audience line ('equity analysts, finance apps and AI agents that need comparable numbers for European listed companies') and by the statement that LEI is 'the most precise lookup, any country', which is really schema text. There is no explicit when-not guidance and no named alternative such as sec_company_financials for US issuers or company_accounts for national filings, so the routing decision is left 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds two pieces of real behavioral context beyond that: the answer is drawn from the consolidated version in force (or as of a given date), and the call costs $0.005 per act-lookup — cost is material for an agent deciding whether to call. It stops short of describing response shape, truncation behavior, or failure modes when an act cannot be resolved.

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?

Front-loaded with the concrete question the tool answers, then the second mode, then audience and price — a sensible ordering with little waste. The 'built for AI agents doing legal and compliance work... without SPARQL' sentence is partly positioning filler, though it does signal the tool replaces raw SPARQL access.

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 10-parameter tool with no output schema, the description covers both modes, the consolidated-version behavior, and cost, while the schema fully documents every parameter. The main gap is that with no output schema, an agent gets no sense of the response structure (how article text, in-force dates and amendment lists are composed) or how maxTextChars truncation manifests.

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 every parameter already carries its own explanation and the baseline is 3. The description's contribution is framing rather than parameter detail — it ties article, asOf, amendments and the OJ mode into a single narrative, but adds no syntax, defaults, or edge-case meaning the schema does not already state.

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-and-resource pair (retrieve article text, in-force status and amendments for an EU act from EUR-Lex) and spells out a second, distinct mode (Official Journal L series listing). It is unmistakably an EU-law tool, which implicitly separates it from national_law_lookup, but it never names or contrasts with that sibling explicitly.

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 two operating modes are described clearly enough that an agent can infer that supplying ojSince switches to OJ listing, and the framing question ('what does Article 50 of the AI Act say today...') gives a concrete use case. There is, however, no explicit when-not-to-use guidance and no routing advice versus national_law_lookup or us_federal_rules for cross-jurisdiction questions.

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?

Annotations already establish readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns latest value plus last-change date plus history, it normalizes plain names instead of SDMX keys, it caps at 20 series, and it states the price model ($0.002 per series). It does not mention rate limits, error behavior for unknown series names, or what an empty result looks like.

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 first sentence front-loads what you get back, the second enumerates coverage, and the price line is short and actionable. The phrase about being built for AI agents and anyone needing a quick sourced number is mild marketing filler that does not help an agent decide anything, but the rest earns its space.

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 seven optional parameters and no output schema, the description does carry the burden of describing return values, and it does so concretely (latest value, when it last changed, the change, recent history). The notable gap is that `catalogue` mode is effectively undocumented in both schema and description, so an agent has no idea what discovery output it would get.

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 all seven parameters including date windows, `last`, `frequency`, and `rawSeriesKey` are already documented in the schema. The description reinforces the plain-name convention and the no-SDMX-keys benefit, and shows inline examples like `ecb_deposit_rate` and `eur_fx:USD`. It adds little beyond the schema and never explains the `catalogue` mode value, which the schema also leaves undocumented.

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 and resource: return the latest value, last-change date, change, and recent history for euro-area rates. It enumerates the covered domains (ECB policy rates, euro reference FX, 60STR, sovereign yields, Eurostat HICP) and states the key differentiator, no SDMX series keys required. No sibling tool covers interest rates or inflation, so an agent can place it accurately.

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?

It gives clear framing (ask by plain name, quick sourced number, 20 series per run, cost per series) but never states when to prefer it over alternatives or when not to call it. The schema exposes a `catalogue` mode and a `rawSeriesKey` fallback, yet the description says nothing about when an agent should use catalogue discovery or escape to raw keys, which are the real routing decisions for this tool.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts: the output is one row per notice with stable field names across countries and notice forms, and pricing is $0.002 per notice — a cost signal unavailable elsewhere and relevant to result sizing.

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 sentences plus a price line, front-loaded with what the tool returns. Some phrasing is promotional ('clean, predictable JSON', the audience list) and could be trimmed, but nothing misleads or buries the essential 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?

With eight optional parameters and no output schema, the description carries the burden of explaining return shape, and it does so for each notice type. Gaps remain minor: it does not say what happens when no filters are supplied or how results are ordered beyond the schema's 'newest first' on maxResults.

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 eight parameters, setting a baseline of 3. The description still adds interpretive value by tying each notice type to the fields it returns (calls carry deadlines and estimated value; awards carry winners and awarded amount), which helps an agent choose noticeTypes and understand what minValueEur compares against.

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 gives a concrete verb and resource ('Get European public tenders and contract awards ... from TED') and enumerates the three notice families with the key fields each carries (deadlines, estimated value, winning companies, awarded amount). The 'European'/'TED' framing implicitly separates it from US-focused siblings like us_federal_awards and dod_contract_awards, though no sibling is named.

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/when-not guidance and no mention of alternatives among the 27 sibling tools. The audience sentence ('For bid teams, tender-alert services, market researchers and AI agents') implies a context but tells an agent nothing about when to pick this tool over, say, us_federal_awards or company_check.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: the shape of the returned records (each value with its source URL) and a per-call price of $0.002, which agents need for cost planning. It says nothing about behavior on ambiguous names or on identifiers that resolve to multiple issuers, which is the main failure mode for a crosswalk.

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 input/output contract is front-loaded in the first clause, followed by audience/use case and then pricing on its own line so cost is easy to find. Slightly dense in the middle (the long output enumeration), but no sentence is redundant.

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, the description carries the burden of describing returns and does so concretely, including source URLs per value. Combined with full schema coverage on inputs and annotations covering safety, an agent has enough to call it correctly; only the ambiguity/error path and 'auto' detection behavior are left open.

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% and the schema itself documents idType, exchange (with Bloomberg and MIC codes) and the identifier formats in detail, so the description only needs to reinforce. It does confirm that exactly one identifier is expected ("One identifier in") and enumerates the accepted identifier kinds, but it never explains the 'auto' default in idType or how detection works. Baseline 3 applies.

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-and-resource pair: it takes one of six identifier types (ISIN, LEI, CIK, ticker, FIGI, name) and returns the full crosswalk (legal name, LEI, CIK, per-exchange tickers, ISINs, FIGIs, CFI, EU venues). That is clearly distinguishable from every sibling, which are domain tools (filings, sanctions, tenders), not identifier joins.

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?

It names concrete situations where the tool applies (KYC, portfolio data, filings research, joining datasets keyed differently) and implies it is the entry point before domain-specific siblings. It stops short of explicit routing, e.g. no instruction on when to prefer sec_company_screen to discover a CIK first, or what to do when a name is ambiguous.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description is not required to establish safety. It still adds real behavioral context beyond them: the text comes from the official consolidated version, reflects the version in force today or on any asOf date, and includes in-force status and amendment provenance. It also discloses a per-call price ($0.005 per act-lookup), which matters for an agent budgeting calls; only failure modes for unknown or ambiguous articles are left unstated.

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 opening clause is well front-loaded with two concrete example questions that immediately anchor the tool. The second sentence ("Built for AI agents doing legal and compliance work, and for people who want a sourced answer without XML") is promotional and largely redundant, though the pricing line that follows carries genuine decision value. Tightening would remove roughly a quarter of the text with no loss.

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 six parameters, no output schema, and only one required field, the definition covers the essentials: what is returned (article text), in what state (in force on a date, with amendment history), and at what cost. Because no output schema exists, the description's sketch of the response contents is genuinely load-bearing. Missing only edge-case behavior, such as what happens when an article reference is ambiguous or not found.

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% and each of the six parameters already carries examples and patterns, so the schema does the heavy lifting. The description reinforces the asOf point-in-time semantics ("today (or on any date)") but adds no syntax, default, or constraint information beyond the schema. A baseline 3 is appropriate.

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 concrete verb and resource: return the section or article text from the official consolidated version in force on a given date, plus in-force status and amendment history. The worked examples ("section 172 of the Companies Act 2006", "artikel 7:658 BW") make the UK/NL statute scope unmistakable. It does not name the near siblings (eu_law_lookup, dutch_case_law), so the agent must infer the boundary itself.

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 conveyed only through example questions about statutes, which implies this is the tool for citing legislation text. There is no explicit when-to-use versus eu_law_lookup (EU instruments) or dutch_case_law (case law), and no stated exclusions or prerequisites. An agent can guess the routing, but the definition does not do the routing for it.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower, yet the description adds real context: the upstream data sources, that CVE lookups also surface NVD's record, and the per-call price of $0.005. It does not cover latency, caching or how ambiguous package/version input is handled, which is the main remaining 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?

The core question and scope are front-loaded in the first sentence, followed by sources and the pricing note. The sentence about being 'built for coding agents and for developers who want a sourced answer instead of a scanner setup' is somewhat promotional but still conveys positioning; overall little waste.

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, the description still tells the agent what answers come back (vulnerability status, in-the-wild exploitation, recommended safe version) and which catalogs back them. Only error or no-match behavior is left unstated, which is minor for a read-only lookup.

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% and already gives examples including Maven group:artifact and Go module paths, so the baseline is 3. The description goes beyond it by enumerating the accepted ecosystem names (npm, PyPI, Maven, Go, crates.io, NuGet, RubyGems, Packagist) and by framing name/version/ecosystem as mutually exclusive with vulnerabilityId.

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?

Opens with a concrete question set (is it vulnerable, is it exploited in the wild, what is the safe upgrade) and names the resource, the sources (OSV.dev, CISA KEV, NVD) and the supported ecosystems. It also distinguishes the two modes, package check vs single CVE/GHSA id, so an agent knows exactly what the call does without opening the schema.

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 makes the two invocation modes explicit ('One call answers it for npm, ... or for one CVE/GHSA id') and positions itself against the alternative of setting up a scanner. It stops short of explicit when-not guidance or stating prerequisites such as which ecosystems need a version supplied.

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?

Beyond the readOnly/idempotent annotations it discloses cost ('Free, no key needed'), determinism semantics ('same question and entities on the same day give the same plan_id'), the echo behaviour in `entities_used`, the `missing` feedback channel, and the degraded-mode behaviour of returning the top 3 candidate tools on low confidence — all behaviour an agent cannot infer from annotations.

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?

Front-loaded with the cost/free signal and the core transformation, and every clause carries information. It is a single dense run-on paragraph, though, so the entity-extraction instruction and the execution guidance are harder to scan than a short structured layout would allow.

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, the description still characterizes the return (plan_id, per-step tool/input/why/max price, entities_used, missing) and the low-confidence variant, and it covers cost and the handoff to execution. An agent can decide whether to call it, what to pass, and what it will get back.

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 still adds real semantics by stating the trust hierarchy (planner trusts supplied entities over its own parsing) and by insisting the question be passed verbatim. It does not add per-field examples beyond the schema, so it stops short of 5.

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 transformation ('turns a question in plain words into the exact typed Bosco Labs calls'), enumerates what each planned step contains (tool, input, why, max price, gaps), and clearly separates itself from the sibling run_official_records_plan and from calling the listed tools directly.

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?

It gives explicit guidance on the two ways to act on a plan ('run it with run_official_records_plan (paid, max_usd) or call the listed tools directly') and on the re-call loop via `missing`. What is missing is a stated when-not-to-use case (e.g. when a single known tool suffices and planning is overhead).

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?

Annotations already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavior: which registries are queried, that results aggregate to one row per query, and the per-call cost ($0.005 per product-check) — cost disclosure is real value an agent cannot get from annotations. It omits rate limits and what happens when a source is unreachable.

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 user-facing question, then sources, then audience, then price — a sensible order with little redundancy. A few marketing phrases ("Built for AI agents... and for people who want...") do not earn their place but are brief enough not to obscure the content.

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 the description compensates by stating the return shape: yes/no per query, recall date, hazard, remedy and official link. Combined with the source list and pricing, an agent has enough to call and interpret it; only failure/degradation behavior and result-ordering beyond maxMatches' "newest first" are absent.

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 the schema already explains euWeeks, queries, sources and maxMatches with examples. The description only restates the accepted identifier formats at a high level, adding nothing about formatting edge cases or how source selection affects results. Baseline 3 is appropriate.

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 the exact question the tool answers ("is this product recalled anywhere, and for what hazard?") and names the accepted identifier types (name, brand, model, UPC/EAN, VIN) plus the four source registries. No sibling tool covers recalls, and the response shape (one row per query) is stated, so an agent can identify the tool at a glance.

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?

It gives implied context through audience framing (e-commerce, resale, procurement, compliance) and the phrase "one sourced answer instead of four searches," which hints at consolidation versus separate lookups. However, it never states when NOT to use it or names an alternative (e.g. identifier_resolver for ambiguous barcodes), so routing is left 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?

Goes well beyond the annotations: parallel execution, hard max_usd refusal semantics ('nothing runs'), per-key billing identical to a direct call, failed steps being free, and the shape of the returned sections/receipt/citations. This is exactly the pricing and failure behavior an agent needs before committing.

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 that are front-loaded with the core action and pack the billing, cap, and return details without filler. The clause stacking in the first sentence makes it slightly harder to parse than it needs to be, but nothing is wasted.

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 the description compensates by naming what comes back (per-step sections with via_tool, via_input, rows with source_url, plus a receipt and citations). For a paid multi-step executor, the cost, failure, and output picture is complete.

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, but the description adds real meaning: plan_id's origin in plan_official_records_query, the all-or-nothing nature of max_usd, and the fact that each step is billed like a direct call. It adds value over the schema's own field descriptions rather than restating them.

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 verb+resource ('Runs a plan') and explicitly ties the input to the sibling planner ('a plan from plan_official_records_query (its plan_id) or explicit steps'), so the agent can distinguish this executor from the planning tool without opening either schema.

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 two clear entry paths (plan_id from the planner, or explicit steps) and an operating constraint (all steps in parallel under a hard cap), which tells the agent when this tool is the right call. It stops short of saying when to prefer one path over the other or what to do when the cap refuses.

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?

Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), and the description adds genuinely new behavior: every response discloses which lists were consulted and their recency, every match links to its official source, and pricing is $0.01 per name screened. It does not state rate limits, batch behavior for the 50-item caps, or what an empty result looks like.

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?

Front-loads the core question, then sources, then return-value behavior, then the wallet capability and price — a sensible order with no true filler. The "Built for AI agents doing KYB..." sentence is the softest part but still earns its place by naming target use cases.

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, the description correctly compensates by describing the return contract: lists checked, data currency, and source links per match. For a six-parameter screening tool with annotations already covering safety, the remaining gap (no mention of rate limits, empty-result semantics, or how minScore interacts with entityType) is modest.

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 the schema already documents all six parameters; the description adds only the nuance that wallet addresses are matched exactly (implying minScore similarity applies to names, not addresses). It says nothing extra about list selection, country scoping, or entityType beyond what the schema states, so the baseline 3 applies.

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?

Opens with a concrete question the tool answers ("is this company, vessel or person sanctioned?") and enumerates the exact sources checked: OFAC SDN/non-SDN, the US CSL (Commerce Entity List, Denied Persons, State), the UK Sanctions List and the EU financial sanctions list. It also names a second distinct capability (crypto wallet screening) so an agent can tell it apart from siblings like company_check or sec_company_screen.

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 clear usage contexts: KYB, compliance and procurement checks for agents, plus a specific pre-payment wallet check. What is missing is any explicit exclusion or routing advice relative to sibling tools (e.g. when to use company_check instead), so the agent must infer that sanctions screening is a distinct check rather than the starting point.

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?

Annotations already declare the tool as read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds valuable context beyond annotations: pricing per company-period, per-value XBRL source citation, and filing provenance, which materially informs an agent's 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?

The description is front-loaded and efficient, with the core capability stated first and the pricing note isolated at the end. It avoids unnecessary repetition of schema details, though it could be slightly tighter.

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 read-only data-retrieval tool with six optional parameters and no output schema, the description covers data source, coverage, metrics, periodicity, identifiers, pricing, and provenance. It is largely complete, though it does not describe pagination or exact row shape beyond the sources fields.

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 input schema has 100% description coverage, so the baseline is 3. The description reinforces key parameter concepts (ticker or CIK, annual or quarterly, 5-20 years) but does not add syntax or constraints beyond what the schema already documents.

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: 'Get clean financial statements of any US-listed company from the SEC's own XBRL data.' It enumerates the covered statement types and distinguishes the tool from parsing filings, making its purpose immediately clear.

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 a use case ('For analysts, finance apps and AI agents that need a company's numbers over 5-20 years without parsing filings') but does not explicitly name alternatives or exclusions versus siblings like sec_filings_feed or esef_annual_reports. Usage is implied rather than fully guided.

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?

Annotations already cover read-only, idempotent, non-destructive and open-world. The description adds genuinely new behavior: per-row XBRL tag and SEC accession/URL citations, and a stated price of $0.002 per screen-row, which matters because maxResults is billed. It does not describe pagination or result ordering limits beyond the argument docs.

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 paragraphs: capability plus examples, audience, then provenance and price. Front-loaded with the screening verb, and no sentence is filler.

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 eight parameters, no output schema and a per-row charge, the description does the right extra work by disclosing citation behavior and pricing. Only gaps are return cardinality/pagination and any note that results are limited to filers with XBRL data for the given period.

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?

Even though schema coverage is 100% (baseline 3), the description adds concrete meaning on top: it maps natural-language screening intent onto the filter/sortBy/metrics triple ('revenue over $10B and net margin above 20%', 'top 20'). It also frames the crop of metric names as revenue, profit, margins, cash flow and balance sheet, so the agent understands the enum's scope without scanning all 36 values.

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 ('Screen every US company that files with the SEC') scoped to financial metrics, with two concrete query examples. It implies bulk screening versus the single-company sibling sec_company_financials but never names or contrasts that sibling explicitly.

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 example queries ('revenue over $10B and net margin above 20% in 2025', 'top 20 by operating cash flow') and the audience line ('analysts, finance apps and AI agents') imply when the tool fits. There is no explicit when-not guidance or pointer to alternatives such as sec_company_financials for one company or sec_filings_feed for filings.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new context: real-time latency ('filings accepted minutes ago'), full history to 1994, the exact fields returned per row, and a per-filing price of $0.001, which is important cost information an agent cannot get from the 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?

Front-loaded with the action and resource, then scope, then row contents, ending with pricing. It is a single dense sentence carrying a lot of enumeration, which is borderline verbose, but nearly every clause adds usable information; the audience list is the weakest part.

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 9 optional parameters, no output schema, and no required inputs, the description does the necessary work by explaining what a returned row contains (company, CIK, ticker, form, filing date, acceptance time, item codes, links) and how far back data goes. Missing pieces are minor, mainly default sort/pagination behavior and whether empty filters return the whole market.

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 parameter semantics are already fully documented in the structured schema. The description mostly restates those filters in prose, adding only light interpretive value via 8-K item code examples (2.02 earnings, 5.02 officer changes, 1.01 material agreements) that the schema also lists. Baseline 3 is appropriate.

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 (Get) and resource (SEC EDGAR filings as clean JSON), enumerates the form families covered, and gives the scope (one company, watchlist, whole market) and historical depth (back to 1994). It does not, however, distinguish itself from close siblings such as sec_company_financials, sec_insider_trades or esef_annual_reports, so an agent still has to infer the boundary.

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 through the scoping options ('for one company, a watchlist or the whole market') and the audience list (investors, news/alert services, compliance teams, AI agents), which hints at freshness-sensitive alerting use cases. There is no explicit when-to-use versus when-not guidance and no named alternative among the siblings.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuine context beyond that: the 2006 coverage horizon, the definition of a cluster (2+ directors/officers, same company, within a window, at least $100,000 combined), and explicit pricing per unit (transaction=9, cluster-signal=100). The only weak spot is that the priced 'unit' concept is never tied to maxResults or includeClusterSignals, leaving a cost-model ambiguity.

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 opening sentence is front-loaded and information-dense, but the description then stacks a cluster-signal sentence, a filter sentence, an audience sentence ('For investors, fintech apps and AI agents'), and a pricing line. The audience sentence earns nothing, and the malformed pricing markdown adds noise rather than clarity.

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 13-parameter, zero-required, read-only query tool with no output schema, the description does a solid job: it enumerates the returned fields so the agent knows the row shape, and explains the cluster record type. What is missing is how the pagination cap (maxResults 200) relates to 'every' transaction and how billing units accrue, which matter for a paid 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 description coverage is 100%, so every one of the 13 parameters is already documented with examples and constraints, which sets the baseline at 3. The description does highlight the main filter axes but adds no syntax, precedence, or interaction rules beyond what the schema states (for example, it does not explain dateFrom vs lookbackDays precedence in its own words). It neither compensates for nor undermines 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?

States a specific verb and resource: retrieve every insider purchase and sale reported on SEC Form 4 back to 2006, with the exact fields returned spelled out (who, what, when, shares, price, post-holding). It also names a distinctive secondary capability, cluster buy/sell signals, which separates it from generic filing feeds. It never names a sibling like sec_ownership or sec_filings_feed, so the boundary with those tools is left for the agent to infer.

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 through the filter list (ticker, CIK, code, role, value, date) and the cluster-signal feature. There is no explicit statement of when to reach for this tool rather than sec_ownership or sec_filings_feed, and no mention of prerequisites or what to do when a query returns nothing. Adequate but with clear gaps for an agent choosing among 27 siblings.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds billing semantics that exist nowhere else — $0.0018 per ownership-row, and each returned row counts as one charged event (reinforced on maxResults). It does not mention rate limits, latency, coverage gaps (e.g. 13F lag), or pagination, so it is helpful but not complete.

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 core capability is front-loaded in the opening clause and the four filing types are packed into one well-structured sentence, followed by a separate one-line pricing statement. It is dense rather than bloated, though the audience sentence ('For investors, analysts and AI agents') is pure filler and could be dropped.

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 13-parameter, all-optional, multi-mode tool with no output schema, the description does the important work: it tells the agent which filing family answers which question and warns that returned rows are billed. Left implicit are the shape of an ownership-row and the behavior of the default mode when no fund, filer, ticker, or cusip is provided.

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% and most parameters already carry per-mode applicability notes, so the baseline of 3 applies. The description adds a little beyond the schema by explaining what 13D vs 13G and Form 144 mean in substantive terms, but it adds nothing about parameter interplay — e.g. that filer vs ticker/cusip are alternative lookup paths within holdings13f, or what happens when mode is left at its default with no subject supplied.

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 precise verb and resource — who owns a stock and who is about to sell it, sourced from official SEC filings — and enumerates the four filing families (13F, N-PORT, 13D/13G, Form 144) with concrete examples (Berkshire Hathaway, VOO, ARKK). It does not, however, differentiate itself from the sibling sec_insider_trades, even though planned144 (insiders filing to sell) clearly overlaps with that tool's territory.

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 routed through real scenarios: fund-manager holdings with quarter-over-quarter changes, mutual fund/ETF holdings, holders of a ticker, 5%+ stake filers split into activist vs passive, and insider sell intent. That gives an agent clear conditions for choosing a mode. It stops short of exclusions — nothing says when to prefer sec_insider_trades, sec_filings_feed, or sec_company_financials instead.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is sourcing and cost: data is read 'live from HMRC' / official USITC search, results include a source link, and search returns at most 5 candidates. It also discloses the per-call price ($0.005), which is useful for agent budgeting and is not in any structured field. Minor gap: no mention of behavior on invalid or unmatched codes.

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?

Front-loaded with the primary action and the fallback mode, then market coverage; the core content is dense and useful. Some promotional filler ('Built for AI agents, customs brokers and e-commerce teams who need a sourced duty rate, not a guess') and the price note could be trimmed without loss.

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?

No output schema exists, and the description does compensate by enumerating return fields for both markets (hierarchy, MFN rate, preferential rates, Chapter 99 refs, units, source link; UK adds VAT and trade remedies). It falls short only on edge cases — no behavior stated for when neither `code` nor `query` is passed, or for unmatched codes.

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 baseline is 3, but the description adds real meaning: it explains the `code` vs `query` trade-off (lookup vs. candidate discovery), what each returns, and how `market` selects the US vs. UK tariff source. `originCountry`, which is relevant to preferential rates, is only explained by 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?

Leads with a concrete verb+resource ('Send a US HTS code and get the official description hierarchy, the general (MFN) duty rate...') and immediately covers both operating modes (code lookup vs. description search) and both markets (US HTS vs. UK Trade Tariff). No sibling tool in the list overlaps, and the tool's scope is unmistakable after the first sentence.

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?

Explicitly routes between the two input modes with 'No code yet? Send a plain product description and get up to 5 candidate codes' and states the switch for the other market via `"market": "UK"`. There are no sibling alternatives to exclude, but it never states what happens if neither `code` nor `query` is supplied, which matters since both are optional.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot carry: per-company pricing ($0.002) with no start fee, which matters for call-volume decisions, and that results come back as 'clean JSON'. It does not mention rate limits, upstream Companies House freshness/latency, or pagination 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?

The core capability and scope are front-loaded in the first clause, and the text is short. The price is stated twice ('$0.002 per company, no start fee' and then 'Price: $0.002 per `company`.') and the audience list is longer than needed, which is minor waste.

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 read-only, fully-schema-documented, six-parameter list tool with no output schema, the definition covers scope, filters, default date window, output format and cost. Nothing critical to invoking it correctly is missing; a field-level return description would be nice but is not required for correct selection.

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 carries the parameter documentation and a baseline of 3 applies. The description adds one thing the schema does not: that omitting dates yields yesterday's incorporations, which defines the default behavior of incorporatedFrom/incorporatedTo that have no schema default. It restates the filter dimensions only at a high level.

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 ('Get every new UK company incorporated') plus the default scope ('yesterday (or on any date range)'), the output shape ('clean JSON'), and the filter dimensions (SIC code, location, company type). An agent can tell this apart from siblings like company_check or sec_company_screen without opening the schema.

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 audience list (sales teams, lead-gen agents, accountants, banks, insurers, web agencies) implies when the tool is useful, and 'yesterday (or any date range)' signals the default call pattern. However, there is no explicit when-not guidance and no named alternative among the siblings for adjacent needs such as company_check or company_accounts.

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?

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety bar is covered. The description adds genuinely useful context beyond them: the upstream source (USAspending.gov) and a concrete price of $0.004 per award, which an agent needs for cost-aware invocation. It stops short of disclosing pagination/row-limit behavior or result-ordering caveats beyond what the sortBy schema field already says.

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?

Front-loaded with the action and dataset, then a single dense clause covering returned attributes and use cases, with pricing isolated on its own line. Every clause carries information and nothing is repeated from the schema or title.

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 14-parameter tool with no output schema, the description does the heavy lifting by enumerating exactly what comes back per award, so the agent knows the response shape. Remaining gaps are minor: it does not flag that awardTypes defaults to contracts only (so grants/loans are excluded unless requested) nor discuss result caps, both of which live only in the schema.

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?

With 100% schema description coverage across all 14 parameters, the schema already carries the semantics and the baseline of 3 applies. The description mentions the same facets the parameters expose (NAICS, PSC, assistance listing, place of performance, tickers/parent company) but adds no extra syntax, matching rules or interaction details beyond the schema 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?

Opens with a specific verb and resource ("Get US federal contracts, grants and loans") and enumerates the returned attributes — winner, agency, amount, date, NAICS/PSC/assistance listing, place of performance, parent company and ticker. "from every agency (USAspending.gov)" implicitly separates it from the DoD-only sibling dod_contract_awards, but the sibling is never named outright, so differentiation is left partly to inference.

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 intended audiences ("sales intelligence, investors measuring government revenue exposure, and procurement or policy research"), which implies when the tool is a fit. It never states when NOT to use it, nor routes the agent to alternatives such as dod_contract_awards for DoD-specific work or eu_tenders for non-US procurement, so the selection logic stays implicit.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is free. The description adds genuinely new behavior: per-unit cost ($0.001; section=5, document=2), temporal coverage bounds (eCFR history from ~2017, FR search back to 1994), and that each part unit carries its own text. It does not discuss rate limits, failure modes, or what happens when a citation resolves to nothing.

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 core capability is front-loaded in the first sentence, and the pricing line is short and useful. The opening nested-quote framing ('One call answers "..."') is slightly marketing-flavored, and the multi-mode enumeration runs long, but no sentence is pure padding.

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 nine-parameter, zero-required, multi-mode read tool with no output schema, the description does the heavy lifting: it sketches what comes back (section plain text, amendment history, underlying final rules) and bounds the cost and history windows. The gap is that with no output schema an agent still cannot anticipate the exact response shape or how an empty result reads, and mode-selection logic remains implicit.

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 the baseline is 3 and the schema already explains asOf, citation, since, and maxResults thoroughly. The description adds only a little semantic linkage — notably that 'since' is used with a part citation to list what changed — but does not clarify the priority or interaction rules among the nine optional parameters, which is the main ambiguity the schema cannot resolve.

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 concrete verbs and resources: it returns a CFR section's text as of a date, its amendment history, the Federal Register final rules behind each change, part-level change lists, and FR documents by number or search. Concrete examples ('21 CFR 101.9', '15 CFR 744 this week') make the scope unmistakable and clearly separate it from siblings like eu_law_lookup or national_law_lookup. It stops short of a 5 because the tool bundles four query modes and the description does not crisply frame them as distinct entry points.

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?

Example queries imply which mode to use ('what does 21 CFR 101.9 say today', '15 CFR 744 this week'), and the stated audience of regulatory/compliance agents sets context. However, it never says when to choose this over a sibling such as eu_law_lookup, nor does it explain whether parameters combine (e.g., citation + since + search) or are mutually exclusive; that has to be inferred from the schema.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the description's added value is the cost model: $1.80 per 1,000 trades, no start fee, charged only for trades delivered, stopping at the max charge limit. It also discloses provenance (official Clerk of the House filings, PTR PDF per row) and result ordering (newest filings first). Minor gap: no mention of pagination or how partial-year coverage behaves when years are omitted.

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?

Front-loaded: the data scope leads, followed by the field list, then audience, then pricing. One waste point exists — pricing is stated twice, once as 'Pricing: $1.80 per 1,000 trades ($0.0018 per trade)' and again as 'Price: $0.0018 per `trade`.' — which is redundant rather than harmful.

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 8 optional parameters, no output schema, and annotations carrying the safety profile, the description supplies what an agent actually needs: data source, time coverage since 2014, per-row fields, sort order, and billing behavior. Pagination and behavior when filters are omitted are the only notable omissions.

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 every parameter (years, filedFrom/filedTo, members, tickers, maxResults, minAmountUsd, transactionTypes) is already documented with examples and constraints. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 ('Get congress stock trades') and immediately narrows scope to trades disclosed by US House members in Periodic Transaction Reports under the STOCK Act. The enumerated output fields (member, state/district, filing date, trade date, days to disclose, owner, ticker, asset type, transaction type, amount range, PTR PDF link) make the result shape unambiguous and separate it from securities siblings like sec_insider_trades.

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 names an audience ('for investors, journalists and AI agents tracking congressional trading'), which implies when the tool fits, but never states when to prefer it over a sibling such as sec_insider_trades or when it is the wrong choice. No prerequisites, no exclusions, no explicit 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it states the checks are live against VIES, describes the per-row result structure, and discloses pricing per check.

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 question it answers and avoids unnecessary repetition. The audience sentence and pricing note are useful, though the middle sentence is long and could be tightened.

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 five-parameter, all-optional validation tool with no output schema, the description gives enough context: it explains the live data source, what each row contains, and the two validation standards. It does not cover edge cases such as partial failures or empty arrays, but the core invocation context is complete.

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 all five parameters are already documented. The description adds some meaning by explaining that expectedName is matched against the company behind the VAT numbers, but overall it does not add much beyond the schema's own parameter descriptions.

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 uses specific verbs and resources: checking EU VAT numbers live against VIES and validating IBANs against ISO 13616. It clearly explains what is validated and what is returned per row, though it does not explicitly distinguish itself from sibling tools such as company_check or identifier_resolver.

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?

It names intended use cases like supplier onboarding, invoice checks, and KYB, which implies when to use the tool. However, it gives no explicit when-not guidance and does not compare itself with sibling tools that might also be relevant.

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