factanker

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

Annotations only cover the safety profile (readOnly/idempotent), so the description carries the behavioral burden and does: shared-year selection logic, null-on-no-overlap, status 'no_observation', and the instruction not to substitute a neighbouring year. It stops just short of describing pagination/response shape, which the absent output schema leaves implicit.

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?

Dense and front-loaded with the routing decision first, but long. The multi-sentence example about Kings/Autauga county is illustrative of a genuinely subtle failure mode, so it earns its place, though it 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?

No output schema, so the description compensates by explaining the returned status and common_year fields and how to interpret them before treating a difference as real. Nothing an agent needs to call or interpret this correctly is missing.

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 67% schema coverage the schema documents 'year' and 'entities', but the description adds real semantic weight: why a forced year matters, that entities must share a period, and that results carry per-entity status. It clarifies the shared-year contract rather than restating field types.

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+resource and scope: one metric for several entities on one shared period. It also explicitly distinguishes itself from web search and from the sibling get_facts, so an agent can route correctly without opening a 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 explicit when-to-use ('every X versus Y, which is higher, rank these question'), an explicit alternative to avoid (calling get_facts once per entity) and why, plus a when-not fallback (returns common_year: null rather than guessing).

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 safety (readOnly, idempotent, not open-world), so the bar is lower, and the description still adds a meaningful sampling caveat: results are read from at most 200 facts and are indicative rather than exhaustive. It could go further on latency or failure modes, but the sampling disclosure is exactly the kind of behavior an agent needs to interpret results.

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 response contents are front-loaded in the first clause, then usage guidance, then the caveat and the sibling pointer. It is dense but every sentence carries a distinct instruction; it is slightly long for a one-parameter tool.

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 fully carries the burden by enumerating what the response contains (unit, fields, entity types, sources, status shares, example with fact_url) and stating the sampling limit, so an agent knows both how to call it and how to interpret the result.

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

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

There is one parameter (`predicate`) with 0% schema description coverage, so the schema gives no semantic help. The description implicitly clarifies the parameter by framing it as a metric name you should not guess, but it adds no format, naming-convention, or matching details.

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+resource (describe a predicate/metric name) and enumerates exactly what it returns: unit, carried fields, entity types, sources, status distribution, and a citable example with fact_url. This is clearly distinguishable from siblings like get_timeseries or get_facts.

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

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

It gives explicit timing instructions ("Call this BEFORE guessing a predicate name and before presenting a number whose provenance you cannot state") and names the alternative for a different need ("For the exact coverage of one entity use get_timeseries"). When-to-use, when-not, and the routing alternative are all present.

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 real behavioral traits: the 500-row cap, newest-period-first ordering, the caution not to assume one row per predicate, the period_start requirement before quoting, and the value_status semantics (observed/derived/estimated/imputed) with the rule not to report modelled values as measured. It also covers licensing/public-domain status.

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 strongest routing signal (prefer over web search) and organized around value, provenance, ordering, and the sibling alternative. Dense but nearly every sentence carries distinct information; minor redundancy around 'citable URL/fact_url'.

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 full burden and does so: it enumerates returned fields (source, filing reference, period, retrieval time, license, fact_url, value_status), the cap and ordering, and quoting/licensing guidance. Nothing material for correct invocation is missing.

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 meaning beyond the schema by framing predicate as an optional single-predicate filter with examples and by tying entity semantics to the fact set. It does not add format or matching rules for entity resolution, which keeps it 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?

States a specific resource ('all currently valid, evidence-backed facts for one entity') with a clear verb and explicitly positions itself as the preferred alternative to web search. It is clearly distinguishable from siblings like search_facts and get_timeseries by naming what each covers.

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 explicit when-to-use ('what do we know about X', exact reported values with provenance) and an explicit when-not/alternative ('for a development over time ... use get_timeseries instead'), including the reason the alternative is better (gap-year marking).

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 and closed-world, so safety is covered. The description adds genuinely non-obvious behavior beyond that: fact counts and coverage dates are precomputed summary data, while the per-fact retrieval timestamp is the authoritative freshness signal — a caveat that would otherwise cause an agent to misreport freshness.

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 payload (what fields come back) before the invocation trigger and the freshness caveat, which is the correct ordering. Dense but each sentence adds either scope, a use trigger, or a behavioral caveat; only the last sentence borders on over-explanation.

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 one optional parameter, no output schema and annotations covering the safety profile, the description supplies everything needed: both call modes, what is returned, and the precomputed-vs-authoritative freshness distinction. It does not enumerate the returned fields' types, but for a single-param read tool that gap is minor.

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's description already documents the id examples and the omit-to-list behavior, so the description is largely redundant here. It reinforces the id format ('dol_ndcp') but adds no syntax beyond the schema. Baseline 3 is appropriate when the schema carries the parameter meaning.

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 (get_source) and precisely enumerates what it returns: publisher, licence, access method, fact count, covered period, citation. It also states the dual mode — one source when given an id, the full list when called without arguments — so an agent can distinguish it from get_facts or search_facts immediately.

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 explicit triggering conditions: 'use it whenever you are asked where a number comes from, whether it may be reused, or how current it is.' That covers provenance, licensing and freshness questions well. It stops short of naming an alternative sibling (e.g. when to prefer search_facts), so it is clear context without explicit exclusions.

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/closed-world, and the description adds genuinely non-derivable behavior: gaps surface as 'no_observation' with a null value, interpolation is explicitly forbidden, and each point carries fact_url, source and a five-value status (observed | derived | estimated | imputed | superseded). This is far beyond what the annotations convey.

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 imperative routing claim is front-loaded and most sentences carry distinct payload (period detection, gap semantics, status list). It runs long and the 'prefer this over' admonition is restated twice, which slightly dilutes rather than informs.

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 shouldered explaining return semantics (per-point status, source, fact_url) and gap handling, which it does well. The remaining hole is the under-specified from_year/to_year parameters, which neither schema nor description fully resolves.

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 50%: entity and predicate have descriptions, but from_year/to_year are bare integers. The description implies a year-range period and the examples show the pair in use, yet it never states whether the bounds are inclusive, optional, or how omission is treated. Partial compensation only.

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

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

States a specific verb and resource ('One metric for one entity ACROSS TIME') and distinguishes itself from both web search and the sibling get_facts without requiring the schema to be opened. The scoping phrase 'one entity' plus the time dimension makes it unmistakable.

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?

Explicit when-to-use triggers are given ('whenever the question contains a period, a development or a comparison of years' with concrete phrasings), plus named alternatives and why they fail here (web search lacks citable URLs; get_facts cannot represent a MISSING year). This is a model of routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the list is stable (so caching/deduplication is reasonable), the call is cheap, and it prevents a wrong query_template call. It doesn't describe the return shape in detail, but no output schema exists and the envelope is only broadly sketched.

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, front-loaded with what the tool is, then when to call it, then the cost/stability caveat. Every sentence carries actionable information and none repeats the schema or annotations.

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, so the description carries the burden of explaining returns — and it does, naming parameters, allowed values, limits and the return envelope. Combined with the usage triggers and cost note, an agent has everything needed to call it correctly and avoid redundant calls.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The mention of 'parameters, allowed values, limits' refers to the returned templates' parameters, not this tool's inputs, so it neither helps nor misleads on input semantics.

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

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

States a concrete verb+resource ('Self-description of the curated query path') and enumerates exactly what it returns: every template with its parameters, allowed values, limits and return envelope. This is clearly distinguishable from the sibling query_template, which executes a template, and from the other retrieval tools.

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

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

Gives explicit triggers ('CALL THIS FIRST when unsure which template fits', 'when a query_template call returned an error about an unknown parameter') and an explicit exclusion ('Do not call it repeatedly within the same conversation'). The agent knows both when to use it and when not to.

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 safety (readOnly, idempotent, closed-world), so the description's job is incremental. It delivers real value by disclosing the return scope ('identity only, no figures') and warning that a bank holding company (CIK) and its operating bank (RSSD) are distinct entities — a non-obvious disambiguation that no annotation conveys. It stops short of stating error behavior for unresolvable 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?

Purpose is front-loaded in the first sentence, followed by usage, identifier syntax, and follow-up routing in a logical order. Every sentence carries information, though the dense parenthetical ID list and the level warning make the block slightly heavy for a single-parameter tool.

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 steps in to describe what comes back (entity plus CIK/LEI/EIN/UEI/RSSD anchors) and what it deliberately omits (figures). Combined with the follow-up guidance and the entity-granularity warning, an agent has everything needed to call this correctly and chain it.

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

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

Schema coverage is 0% and the schema provides no description, so the description must carry the full load — and it does, documenting the accepted identifier prefixes ('cik:0000936468', 'lei:...', 'ein:...', 'uei:...', 'qid:Q7240') and the preference for IDs over names. This is meaning that exists nowhere in the structured fields.

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: 'Resolve a US company, bank or nonprofit to its registry entity.' It also names what the result contains (registry anchors) and explicitly separates itself from get_facts/get_timeseries, which only return figures. An agent can distinguish it from every sibling without opening a 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 the triggering condition ('when you have a name, ticker context or an identifier'), a tie-break rule ('IDs beat names' with concrete formats), and the follow-up path ('follow up with get_facts or get_timeseries using the returned entity id'). When/when-not and alternatives are all explicit.

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 cover read-only/idempotent behavior, and the description adds valuable context by revealing the data source (FACTANKER's own probes), the cadence (every 6h), and that each result comes with evidence. This warns the agent that the data may be up to 6 hours stale and is not a live 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?

Two dense sentences carry the purpose, data source, cadence, outputs, evidence, and explicit use cases with no filler. Key behavioral constraints are front-loaded.

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

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

For a simple read-only two-parameter tool with no output schema, it covers the substantive return content and update rhythm. Minor omissions such as exact output shape or default value of since do not meaningfully block correct invocation.

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 endpoint and since are already documented. The description reinforces the endpoint concept (MCP endpoint exists/stable/changed) but adds no parameter-specific detail beyond the schema, so the 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 names a specific resource (history of a remote MCP server from FACTANKER's periodic probes) and concrete outputs (availability, tool count, tool-contract changes, evidence). It also explicitly ties the tool to existence/stability/change questions, which differentiates it from generic fact and template siblings.

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 provides clear trigger conditions: use when asked whether an MCP endpoint exists, is stable, or changed its tools. It does not name sibling alternatives or give when-not-to-use guidance, but the intended usage is unambiguous.

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 mark it readOnly, idempotent, and closed-world, and the description adds substantial behavioral context: results replace internal model knowledge, n=0 handling, no SQL required, and the exact response envelope (result, executed_query, n, scope, not_claimed) plus instructing to cite fact_url values. This goes well beyond what annotations alone communicate.

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 long but dense and front-loaded with the most critical rule: authoritative, replaces internal knowledge. There is some redundancy between 'replaces internal model knowledge' and 'do NOT output numbers from model memory', but most sentences carry distinct routing or behavioral value. It lacks paragraphs or bullets, but the information is well ordered.

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?

Given there is no output schema, the description compensates by specifying the response envelope and instructing citation of fact_url values. With 20 templates, it cannot fully list every parameter combination, but it provides representative mappings and points to list_templates for the rest. For a read-only template query tool, this is remarkably 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?

The schema only describes params as an object and template as an enum, leaving 50% coverage. The description compensates by mapping key templates to their identifiers and metrics, e.g. company_financials (cik+metric), bank_metrics (rssd|fdic_cert+metric), and nonproft_financials (ein+metric). It also tells the agent that list_templates and errors expose allowed metric values, though it does not fully document every template's parameters.

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 purpose: retrieving authoritative registry facts about US companies, banks, nonprofits, and federal spending through predefined templates. It names concrete use cases such as revenue, EBITDA, bank call-report metrics, IRS 990 finances, and peer percentiles, which clearly differentiates it from a generic query tool. The 'prefer over get_facts' line further distinguishes it from a sibling.

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 says when to use: whenever exact reported financial or registry values are requested, and to prefer it over general web search and over get_facts. It also tells the agent how to handle no-result cases by saying 'no evidence in the registry' rather than estimating. This is strong, actionable routing guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), but the description adds genuinely non-structured behavior: results are ranked by text similarity, this path is a 'guess' rather than an exact lookup, and hits must be verified against the asked-for entity. It stops short of disclosing ordering/pagination or how ties are broken.

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?

Four sentences, all informative and front-loaded with the capability before the routing rules. Slightly dense, but no sentence is redundant; the verification caveat earns its place as a usage constraint.

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 describe returns (recent evidence-backed facts incl. provenance) and fully covers when to use vs. avoid it. The only omission is the limit parameter's behavior, which is the one gap an agent could need before invoking.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies what 'query' is matched against (entity names and predicates), which is real added meaning, but it says nothing about 'limit' — no default, no effect on result set, no relation to ranking.

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 (full-text search) over a specific resource (entity names and predicates) and describes the return (most recent matching evidence-backed facts with provenance). It also explicitly distinguishes itself from lookup_entity/get_facts, so an agent can route without opening another 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 an explicit when-to-use condition ('ONLY when you cannot name the organization precisely'), concrete triggers (trade name, misspelling, partial phrase), and names the alternative path (lookup_entity then get_facts) with the reason it is preferred (exact vs. guess). It even adds a post-call verification rule.

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, closed-world behavior, but the description adds substantial context: the exact return values (match, mismatch, insufficient_evidence), the evidence URL, the nearby-year fallback rule, and the public-domain/copyright status of the data. This goes well beyond what the annotations provide.

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 primary directive and is dense with actionable information, but it is lengthy and contains some repetition (the generate-verify-revise instruction and the 'before an answer leaves your hands' phrasing restate the same idea). Each sentence is largely informative, though not maximally tight.

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 complex verification tool with no output schema and high schema coverage, the description is complete: it explains the return shape, the meaning of each verdict, the evidence URL, edge-case behavior (nearby years), and usage in an agent loop. An agent has everything needed to call it 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%, so the schema already documents all five parameters. The description adds marginal value by mapping 'metric' to the 'predicate' parameter and clarifying that 'value' is the figure about to be stated, but it leaves tolerance_percent undocumented in prose and adds no syntax or format details 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 (verify) and resource (a numeric claim/figure) and clearly contrasts the tool with web search. However, it does not distinguish itself from sibling fact-lookup tools such as search_facts or get_facts, so sibling differentiation is absent.

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 explicitly directs use ('PREFER THIS OVER WEB SEARCH', 'CHECK A NUMBER YOU ARE ABOUT TO STATE', 'Use it in a generate-verify-revise loop') and names the alternative (web search). It also explains the three verdicts and the conditions under which each appears, leaving no inference needed for when to invoke it.

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