Authenticated public evidence search, verification, research jobs, exports, and webhooks.
Scored across 34 tools
Most tools target distinct resources, but the four search tools (evidence_search, evidence_semantic_search, evidence_universal_search, evidence_search_entities) overlap enough to cause misselection. Numerous read/status/history tools are distinguishable only by careful attention to their resource-specific descriptions.
Every tool uses the evidence_ prefix and snake_case, which is highly consistent. However, naming mixes verb_noun patterns (evidence_get_export, evidence_create_webhook) with noun-only labels (evidence_products, evidence_usage), slightly reducing predictability.
With 34 tools, the surface is heavy and includes many granular status/health/history variants for webhooks, exports, and research jobs. This exceeds the typical 3-15 well-scoped range and feels over-expanded for a single MCP server.
The set covers search, documents, claims, exports, research, webhooks, usage, products, sources, datasets, and benchmarks with reasonable lifecycle support. Minor gaps exist, such as no explicit list/cancel operations for exports or research jobs and no document listing beyond search.
List public benchmark definitions and recent runs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description usefully adds that results combine benchmark definitions with recent runs and are restricted to public ones, but it does not cover result size, ordering, or truncation behavior for the run list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly the source of the coverage gaps elsewhere.
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 listing tool with annotations covering safety and no output schema, the description is minimally adequate: the two result types are named. It falls short on the one parameter's semantics and on any hint about volume or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single `limit` parameter, and the description says nothing about it — no default (20), no range (1-50), and no indication of whether it bounds definitions, runs, or both. With the schema providing no prose, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("List") with a specific resource ("public benchmark definitions and recent runs") and scopes it to public benchmarks. It does not, however, distinguish this tool from adjacent read-only siblings such as evidence_datasets or evidence_sources, so an agent must 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?
There is no statement of when to use this tool, no prerequisites, and no mention of alternatives among the many read-oriented siblings. The agent is left to guess whether this is the canonical source for benchmark data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent public evidence change events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the 'recent' and 'public' scoping qualifiers; it says nothing about pagination behavior, ordering, or what a change event contains, so it adds limited value beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Nothing is wasted, though the terseness is also where the information gaps come from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (read-only, one optional parameter, no output schema), so the burden is modest. Still, the description omits ordering, recency window, and the nature of a 'change event', which an agent would want in order 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?
The single 'limit' parameter has 0% schema description coverage, and the description never mentions it. With coverage below 50%, the description should compensate by explaining what the limit bounds, but 'recent' is the closest it comes, leaving the parameter's meaning to be guessed from its name.
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 (List) and resource (public evidence change events) with a scope qualifier (recent). An agent can grasp what it returns without opening the schema, though the description does no work to set it apart from near-neighbors such as evidence_claim_timeline or evidence_version_claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given, and no alternative is named. 'Recent public' implies a lightweight change-feed use case but the agent is left to infer when this is preferable to the many other evidence listing/search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the bounded public supersession timeline for a claim key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| claimKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world behavior, so the safety profile is covered. The description adds meaningful context by disclosing that the timeline is 'public' (data exposure scope) and 'bounded' (result is capped), but it omits ordering, completeness, and what supersession events actually contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb first and no filler. It is appropriately sized, though its brevity comes at the cost of the guidance and parameter detail noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% parameter coverage, the description carries the full burden of explaining the return shape, ordering, and limit semantics, and does not. 'Supersession timeline' is left undefined, so an agent cannot predict what the read actually yields.
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 compensate for both parameters. It identifies the required 'claim key' concept and hints at bounding via 'bounded' (the limit param), but provides no format, uniqueness, or limit-range detail, leaving both documented nowhere.
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 ('Read') and a concrete resource ('bounded public supersession timeline for a claim key'), so an agent knows the operation and its scope. It does not, however, differentiate itself from nearby siblings such as evidence_version_claims or evidence_changes, leaving the agent to guess which timeline-style tool applies.
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 contains no when-to-use guidance, prerequisites, or named alternatives. There is no signal about when this should be chosen over evidence_version_claims or evidence_verify_claim, which is exactly the ambiguity a timeline tool needs to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one bounded public JSONL export job.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| format | No | jsonl | |
| datasetId | Yes | ||
| recordLimit | No | ||
| selectionStrategy | No | balanced |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description only needs to add context. "Bounded" hints at the recordLimit cap, but it omits the significant non-idempotent behavior (repeat calls spawn duplicate jobs), any auth/rate-limit notes, and lifecycle expectations. Minimal value beyond 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?
A single tight sentence with the verb front-loaded and no filler. It is efficiently written, though its brevity here reflects under-specification rather than disciplined editing.
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 no annotations describe returns, yet the description says nothing about what the created job yields, its identifier, status, or how pagination/cursor interacts with recordLimit. For a 5-parameter mutating tool with 0% schema coverage, this is a substantial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description carries the full explanatory burden. It only gestures at bounding via "bounded" and never explains cursor, format, selectionStrategy (balanced vs recent), or the recordLimit maximum of 500. The two enums are left entirely to 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?
Specific verb+resource ("Create ... export job") that cleanly distinguishes it from the sibling read tools evidence_get_export, evidence_get_export_artifact, and evidence_get_export_manifest. However, it states the job is "JSONL" while the format parameter also accepts parquet, which slightly narrows the tool's actual scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the retrieval siblings, no mention of prerequisites, auth, or what to do after the job is created. The agent must infer the entire create-then-fetch workflow from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one bounded source-cited research job.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the safety bar is covered. The description adds that jobs are 'bounded' and 'source-cited', which is real behavioral context about scope and output grounding, but it omits that this is likely an asynchronous job requiring polling and what the cost/quota implication is.
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?
One front-loaded sentence with no filler; the verb and resource arrive immediately.
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 job-creating mutation with no output schema, the description does not say whether the call returns a job id, whether execution is asynchronous, or how to retrieve the result through the get_research siblings. Key operational context 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?
The single 'query' parameter has 0% schema description coverage and the description never mentions it, so neither source explains what the query should contain, its 300-character bound, or how it is interpreted.
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 ('Create') and resource ('research job'), qualified by 'bounded' and 'source-cited'. It implies the contrast with the retrieval siblings (evidence_get_research, evidence_get_research_artifact) but never names them, so an agent must infer the create-vs-fetch split.
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 statement of when to use this tool versus alternatives, no prerequisites, and no mention that results are fetched through evidence_get_research. The agent gets no routing guidance at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an owner-scoped allowlisted signed webhook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| eventTypes | Yes | ||
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-idempotent, non-destructive, non-read-only write with no open-world access. The description adds two real behavioral facts beyond that: the target URL must be 'allowlisted' (a precondition/workflow constraint) and deliveries are 'signed' (implying a signing secret is involved). It still omits permissions required, what happens on duplicate subscriptionKey, and what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; 'owner-scoped allowlisted signed' are all load-bearing qualifiers. It is dense but not padded, though the terseness trades away useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should say what is returned (e.g., the subscription id and signing secret) and whether the secret is shown only once. It also omits prerequisites such as admin scope or URL allowlisting steps, leaving an agent short of what it needs 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 coverage is 0% and all three parameters (subscriptionKey, url, eventTypes) carry no descriptions. The description hints that 'url' must be allowlisted but says nothing about the meaning or format of subscriptionKey or the eventTypes enum values, so it fails to compensate for the coverage gap.
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?
Specific verb ('Create') plus resource ('webhook subscription') with qualifiers 'owner-scoped' and 'signed'. An agent can distinguish it from evidence_list_webhooks, evidence_set_webhook_status, and evidence_rotate_webhook_secret, though the description never names those alternatives 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?
No when-to-use guidance, no exclusions, and no routing to siblings such as evidence_send_webhook_test or evidence_set_webhook_status. The reader is left to infer that this is the entry point for registering a new subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public dataset selection contracts and immutable snapshot provenance, coverage, freshness, and citation metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and closed-world scope, so the safety profile is covered. The description adds the notion of 'immutable snapshot provenance', which conveys data stability, but says nothing about pagination, auth, or result size for what is clearly a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the resource and returned facets are stated immediately. It is jargon-dense but every clause earns its place.
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 list tool with annotations covering safety and no output schema, the description conveys what the items represent, which is largely sufficient. However, it omits any paging/limit behavior, which is the one operational detail an agent needs 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 0% and the single 'limit' parameter is undocumented in both schema and description. The description never mentions limiting, paging, or result count, so it does not compensate for the coverage gap even though the schema bounds (1-50, default 20) hint at the intent.
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 (List) and a concrete resource (public dataset selection contracts plus snapshot provenance, coverage, freshness, citation metrics). An agent can tell this is the datasets-listing tool, but it does not explicitly distinguish itself from near-siblings like evidence_sources or evidence_source_registry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as evidence_sources or evidence_benchmarks. The agent must infer the selection context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public evidence document by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds one genuine piece of context not in the annotations: only 'public' documents are retrievable. It says nothing about error behavior for missing/non-public IDs, but with annotations doing the heavy lifting a 3 is appropriate.
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?
One short sentence with no filler, and the key constraint (single document, by ID) is front-loaded. It is efficient, though too terse to earn a 5.
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 single-parameter read tool with rich annotations and no output schema, the description covers the essentials. Only the public-vs-private access limitation and retrieval source are touched on; no return-format detail is needed given no output schema exists.
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 schema documents only type and length bounds. The description adds the meaning of the single parameter ('its ID' identifies the document), but no format, source, or validity detail. For a single self-evident identifier parameter, this is minimally adequate.
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 (read), resource (evidence document), and scoping condition (by its ID, one document). This is clear enough to distinguish from listing/searching siblings like evidence_search or evidence_benchmarks, though it does not name an alternative 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?
There is no explicit when-to-use guidance or routing to alternatives. The phrase 'by its ID' weakly implies the caller must already hold an ID, but nothing states when to use this versus evidence_search or evidence_universal_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read effective free-beta product access for the authenticated owner.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description does add one piece of context beyond the annotations: the result is 'effective' access (resolved/computed rather than raw configuration) and is implicitly scoped to the calling identity, which explains why no parameters exist. It says nothing about caching, freshness, or what the entitlement set 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?
A single front-loaded sentence with no filler or redundancy. Every word carries information and nothing is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is low, annotations are rich, and there are no parameters, so the description covers the essential minimum. The notable remaining gap is the return shape: with no output schema, an agent cannot tell whether the response is a boolean, a feature list, or a per-product access map, and the description does not say.
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 phrase 'for the authenticated owner' usefully confirms that the subject is derived from the caller's credentials rather than supplied by the caller.
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 ('Read') and a specific resource ('effective free-beta product access') scoped to the authenticated owner, which is more informative than a tautology. It does not, however, distinguish itself from similarly themed siblings such as evidence_products, evidence_quota, or evidence_usage, so an agent must guess at 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?
The description gives no when-to-use guidance, no prerequisites, and no pointer to an alternative tool. An agent knows what the tool reads but not the situation that should trigger it instead of evidence_products or evidence_quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one owner-scoped export job status.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description's only added behavioral detail is the 'owner-scoped' access constraint, which hints at permission boundaries but says nothing about pagination, retention, or error behavior when the job 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?
A single short sentence with the resource and scope front-loaded and zero filler. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with full annotations and no output schema, the description is minimally viable. It falls short only on explaining the jobId's origin and its relationship to the export artifact/manifest tools, which an agent needs to sequence calls 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 0% and the single required parameter 'jobId' is undocumented in both the schema and the description. The description does not say where the jobId comes from (presumably evidence_create_export) or that it is an opaque identifier, leaving the only input to the tool unexplained.
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 ('Read'), resource ('export job status'), and cardinality/scope ('one owner-scoped'), which distinguishes it from the plural list tools and from evidence_create_export. It does not, however, explicitly differentiate itself from evidence_get_export_artifact or evidence_get_export_manifest, which are the nearest 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?
There is no when-to-use guidance and no routing to alternatives. An agent cannot tell from the description whether to call this before or after evidence_get_export_artifact, or under what job state it is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve one authenticated first-party export artifact stream.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
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's only added signal is 'authenticated,' which hints at an auth requirement but never states whose credentials or what scope. Critically, it says nothing about the artifact 'stream' itself - whether it returns bytes, a signed URL, or chunked content, or any size/expiry 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?
The single sentence is short but not concise in the useful sense: it is so compressed with unexplained jargon ('resolve,' 'first-party,' 'artifact stream') that it conveys almost no actionable information. Brevity here comes from under-specification rather than economy.
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 parameterized retrieval tool with no output schema and no parameter documentation, the description should carry the bulk of the explanatory load. Instead it omits the meaning of jobId, the nature of the returned artifact stream, and how this differs from the several sibling export/artifact tools, leaving an agent without enough to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter, jobId, is never mentioned in the description. The agent cannot tell whether jobId is an export job identifier, a research job identifier, or something else, nor how it relates to the artifact being resolved. With one undocumented parameter, the description fails to compensate for the coverage gap.
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 pairs a verb ('Resolve') with a resource ('export artifact stream'), so the general domain is identifiable. However, 'resolve' is opaque (does it fetch metadata, bytes, or a URL?) and 'authenticated first-party' is unexplained jargon. It offers no differentiation from close siblings like evidence_get_export, evidence_get_export_manifest, or evidence_get_research_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus evidence_get_export or evidence_get_export_manifest, nor any stated prerequisites such as needing a completed export job first. The agent must infer the position of this tool in the export workflow entirely on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the immutable buyer-readable provenance and coverage manifest for an export.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the manifest is 'immutable' and 'buyer-readable', which is genuine behavioral context, but it says nothing about return format, pagination, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is dense but every clause carries meaning, though the compressed jargon slightly reduces immediate readability.
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 one-parameter read tool with a full set of annotations and no output schema, the description covers purpose but leaves the sole parameter and the distinction from sibling export tools unaddressed. Adequate but with clear gaps.
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 single parameter jobId has 0% schema description coverage, and the description never mentions it — the closest hint is 'for an export'. With a low coverage schema, the description is expected to compensate for the undocumented identifier, and it does not.
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 ('Resolve') and resource ('provenance and coverage manifest for an export'), so the agent knows it retrieves a manifest rather than the export itself or an artifact. However, it does not explicitly distinguish this from close siblings like evidence_get_export or evidence_get_export_artifact, and the phrase 'buyer-readable provenance and coverage manifest' is opaque jargon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of the alternative tools (evidence_get_export, evidence_get_export_artifact) that a caller might confuse this with. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one owner-scoped research job status.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The only added value is the 'owner-scoped' qualifier, which signals that only the caller's own jobs are returned. No pagination, error behavior, or status semantics are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the purpose and scope lead. It is terse to the point of being under-specified, but there is no wasted structure.
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 is responsible for describing the returned status, but it does not (status values, lifecycle states, whether artifacts are included). For a one-parameter read tool with strong annotations the minimum is met, but the return-value semantics remain a real gap.
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% and the single required parameter jobId is undocumented in both schema and description. The description does not say where jobId comes from (presumably evidence_create_research) or its format, so it fails to compensate for the coverage gap.
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 (Read) and resource (research job status) with narrowing scope (one, owner-scoped). It does not explicitly contrast with the nearest sibling evidence_get_research_artifact, so it falls short of a 5, but an agent can tell it retrieves job status from the name/description pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as evidence_get_research_artifact for the produced output. The agent must infer the usage context entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve one authenticated first-party research artifact stream.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds only that the artifact is 'authenticated' and 'first-party', which is mild extra context beyond the annotations but nothing about format, streaming behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, but it is under-specified rather than efficient — the terse phrasing trades away meaning. Adequate minimum, no more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose only input is an undocumented jobId and with no output schema, the description should explain what is returned and how the jobId is obtained. It omits both, leaving the agent unable to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single required parameter (jobId) is never mentioned in the description, so it must compensate and does not. The word 'authenticated' hints at an auth context but says nothing about what the jobId identifies or where it comes from.
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 verb ('Resolve') and a resource ('research artifact stream'), so the general intent is inferable, but 'resolve ... stream' is jargon and the description never distinguishes this from close siblings like evidence_get_research or evidence_get_export_artifact. The agent gets a hint, not a crisp purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative. With 30+ siblings including evidence_get_research and evidence_get_export_artifact, the description gives the agent nothing to route on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List owner-scoped webhook subscriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description's only added behavioral signal is the 'owner-scoped' scoping constraint; it says nothing about pagination, ordering, or what a subscription record contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the resource and its scope front-loaded; there is no filler or redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list with no parameters, the description plus annotations cover the essentials. With no output schema, though, an agent gets no hint about return shape, pagination, or ordering, which are the remaining gaps for this tool class.
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 and schema coverage is reported at 100%, so there is nothing for the description to clarify. Baseline of 4 applies for a no-parameter tool.
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 ('List ... webhook subscriptions') plus a scope qualifier ('owner-scoped'), which separates it from the create/rotate/set-status webhook siblings. It does not, however, distinguish itself from other read-style webhook tools such as evidence_webhook_history, evidence_webhook_availability, or evidence_webhook_health.
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?
'Owner-scoped' hints at the result set boundary but gives no when-to-use guidance, no prerequisites, and no pointer to alternative webhook-listing tools. An agent must infer on its own whether this or evidence_webhook_history is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List current evidence API product definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — it does not mention pagination behavior, the shape of a 'product definition', or whether results are cached/live, despite the presence of a limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero waste. It is appropriately sized for the tool's simplicity, though it could afford one clause of extra context without becoming 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?
For a no-required-param, read-only list tool with annotations covering safety, the description is barely sufficient, but it omits pagination semantics and what a 'product definition' contains. With no output schema, the agent gets no help understanding the return payload.
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 compensate for the undocumented limit parameter, but it never mentions pagination, defaults, or maximums. The schema conveys bounds (1-50, default 20) but the description adds no meaning on top of 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?
States a specific verb ('List') and resource ('evidence API product definitions'), so the agent knows it is a read-style enumeration of product metadata. However, it offers no differentiation from similarly named siblings such as evidence_sources, evidence_datasets, or evidence_benchmarks, leaving the agent to infer the distinction from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives among the many evidence_* siblings. The agent must infer that this is a discovery/introspection call rather than a data-retrieval call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the authenticated agent's current usage quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only that the quota belongs to the authenticated agent and is 'current' (live), which is modest extra context but not deep behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. Nothing can be trimmed without losing 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?
For a no-param, read-only call this is close to sufficient, and the lack of an output schema means return-value explanation is not required. Still, it never clarifies what the quota measures (limit, remaining, reset window) or how it differs from evidence_usage/evidence_entitlements, leaving a real ambiguity for the 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?
The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. Per the zero-parameter baseline, a 4 is appropriate with no meaningful gap.
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 (Read) and resource (the authenticated agent's current usage quota), so the operation itself is unambiguous. However, it does nothing to separate itself from close siblings like evidence_usage and evidence_entitlements, which an agent could easily conflate with quota.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no stated preconditions, and no mention of alternatives such as evidence_usage or evidence_entitlements. The agent is left to infer the selection criteria entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay one stored webhook event with bounded replay protection.
| Name | Required | Description | Default |
|---|---|---|---|
| eventKey | Yes | ||
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The phrase 'bounded replay protection' adds a genuine behavioral trait beyond the annotations, but it is left undefined — the agent cannot tell whether this means a rate cap, a dedupe window, or a one-shot guard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though the terseness is part of why the parameter and re-use semantics go unexplained.
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?
Annotations cover the safety profile and there is no output schema to explain, so the gaps are narrower than they first appear. Still, for an open-world, non-idempotent mutation with two undocumented parameters, the description leaves an agent short of what it needs to invoke this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for both required parameters, yet it mentions neither subscriptionKey nor the format/meaning of eventKey. 'One stored webhook event' only loosely implies an event identifier and gives no hint about the subscription key's role.
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 plus resource: 'Replay one stored webhook event.' The word 'stored' and 'one' scope it precisely, distinguishing it from evidence_send_webhook_test (live test) and evidence_webhook_history (read). It doesn't explicitly name those siblings, but the operation is 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?
No when-to-use guidance and no alternatives named. With siblings like evidence_send_webhook_test and evidence_webhook_history in the same domain, an agent gets no signal about when replay is the right choice versus triggering a fresh test send or inspecting history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate a webhook signing secret and return it once.
| Name | Required | Description | Default |
|---|---|---|---|
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation and non-idempotency profile is covered structurally. The description adds genuinely useful context beyond that — 'return it once' warns the agent the secret is not retrievable later. However, it omits the key operational consequence of rotation: that the previous secret is immediately invalidated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and includes only one additional clause, the one-time return. Every word earns its place with no 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?
For a simple one-parameter mutation tool with no output schema, the description covers the essential mechanic (rotate, return once) but leaves out the invalidation effect on the existing secret and any detail about the subscriptionKey argument. Adequate but with clear gaps for a security-sensitive operation.
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% and there is one required parameter (subscriptionKey) whose meaning is not elaborated anywhere. The description says nothing about which webhook subscription is targeted or what form the key takes, so it fails to compensate for the documentation gap.
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?
Specific verb+resource: 'Rotate a webhook signing secret' is unambiguous and clearly distinct from siblings like evidence_list_webhooks, evidence_create_webhook, and evidence_set_webhook_status. It stops short of explicitly naming an alternative, but the action is unique enough among siblings that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no reference to sibling tools. The agent is not told when rotation is appropriate (e.g., compromised secret, scheduled rotation) or what happens to the prior secret.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search normalized current public evidence documents.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is fully covered. The description does add useful scoping context beyond the annotations — results are limited to 'current' (not historical) and 'public' documents — which is meaningful given siblings like evidence_version_claims. It still says nothing about result volume or pagination beyond the limit param.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and no redundancy, which is well front-loaded. The problem is under-specification rather than verbosity, so it cannot score 5 — the sentence is efficient but does too little work for a search entry point.
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 should at least hint at the shape of results, and with 0% parameter coverage it should explain the required query. Neither is present, and the crowded sibling namespace demands differentiation that is absent. For a primary search entry point this is under-described.
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 carries the full burden for explaining 'query' and 'limit' — and it mentions neither. It does not state what query syntax is accepted (keyword, boolean, natural language), nor what limit bounds mean in practice, leaving both parameters semantically bare.
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 (Search) and a reasonably specific resource (normalized current public evidence documents), which is clearer than a bare 'search'. However, it does nothing to distinguish this tool from its three obvious siblings — evidence_semantic_search, evidence_universal_search, and evidence_search_entities — so an agent cannot tell from the text alone which search variant applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all, and critically no routing between this and the other search siblings (semantic, universal, entities). The agent must infer the use case entirely from the name, which is risky given four overlapping search tools in the same family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search normalized public evidence entities.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety and idempotency profile is covered. The description adds the scoping fact that results are 'normalized public' entities, which is meaningful context beyond annotations. It does not disclose result format, pagination, or scoring, but the annotation coverage lowers the burden.
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?
One short sentence, front-loaded with the verb, which is structurally fine. But it is under-specified rather than concise – the brevity comes at the cost of needed information rather than from removing 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 search tool with 0% schema description coverage and no output schema, an agent needs to know query semantics and result shape. The description supplies neither, and gives no differentiation across three sibling search tools. Incomplete relative to the tool's complexity.
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 compensate, and it does not. Neither 'query' (the matching semantics – exact, prefix, full-text?) nor 'limit' (default 20, max 50, pagination behavior) are explained anywhere. This is a real gap for a search tool where query semantics determine correctness.
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 verb (Search) and resource (normalized public evidence entities), which is more specific than a tautology. However, the sibling set contains evidence_search, evidence_semantic_search, and evidence_universal_search, and the description offers no differentiation from any of them. An agent cannot tell which search tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no mention of the three closely-named search siblings. The description gives no condition that would route an agent to this tool over evidence_search or evidence_semantic_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public corpus with feature-gated semantic enhancement and lexical fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| idempotencyKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds one useful behavioral fact — semantic enhancement is feature-gated and degrades to lexical fallback — but says nothing about auth requirements, rate limits, or result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb and resource first. It is compact with no filler, though "feature-gated" is jargon that costs some 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?
A search tool with three undocumented parameters, no output schema, and no annotation coverage of inputs needs the description to carry more weight. It omits query semantics, result format, and the reason an idempotencyKey is mandatory.
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% and the description mentions no parameters at all. It gives no meaning for query syntax, the limit cap, or why an idempotencyKey is required for a read operation, so the three parameters remain fully opaque.
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 ("Search the public corpus") and adds the search mode (semantic enhancement with lexical fallback), which is more than a tautology. However, it does not distinguish this tool from close siblings like evidence_search or evidence_universal_search, so an agent cannot tell from the description alone which search endpoint to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. It never says when semantic search is preferable to evidence_search or evidence_universal_search, nor any prerequisite for the feature gate being enabled. The implied context (semantic passes) is present but no routing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send one signed test event to an active webhook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| eventType | Yes | ||
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the agent knows this is a non-destructive but non-idempotent write with external effects. The description adds that the event is 'signed' and 'one' event (reinforcing the non-idempotent single-delivery nature) and that the subscription must be active, which is useful context beyond the 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?
A single efficient sentence with the action and target front-loaded. No wasted words, though the brevity comes partly at the cost of the missing parameter and behavioral detail.
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 only two parameters, no output schema, and 0% schema coverage, the description is too thin for the task. It never explains the subscriptionKey parameter or what a successful test delivery returns or affects, leaving the agent to infer invocation details.
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 neither subscriptionKey nor eventType is documented in the schema, and the description adds no meaning about either. The eventType enum is self-documenting, but subscriptionKey's role (which subscription to target, key format) is left entirely unexplained, so the description fails to compensate for the coverage gap.
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 (Send) and resource (one signed test event to an active webhook subscription), which is distinguishable from siblings like evidence_replay_webhook_delivery or evidence_webhook_health. It is clear, though it doesn't explicitly differentiate itself from those alternatives by name.
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 phrase 'to an active webhook subscription' implies the precondition that a subscription must exist and be active, and the word 'test' implies a trial/diagnostic context. However, there is no explicit when-to-use or when-not-to-use guidance versus replay or health-check siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause, resume, or revoke an owner-scoped webhook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=false, idempotent=false, and openWorld=false. The description adds 'owner-scoped', which hints at an authorization boundary, but says nothing about whether revoke is reversible, whether paused subscriptions can be resumed, or what happens to in-flight deliveries — meaningful gaps for a status-mutation tool that includes a revoke option.
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?
One tight, front-loaded sentence with zero filler. It is efficient, though arguably undersized for a mutation tool with two undocumented parameters and an enum of three new states.
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 write tool with no output schema and 0% schema description coverage, the description omits status-transition rules (can a revoked subscription be reactivated?), permission requirements, and the effect of each status. An agent has to guess at the allowed lifecycle.
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 parameter meaning. The verbs loosely map to the status enum values (pause→paused, resume→active, revoke→revoked), but subscriptionKey is entirely unexplained and no parameter is named. This falls well short of compensating for the coverage gap.
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 specific verbs (pause, resume, revoke) acting on a clearly named resource (owner-scoped webhook subscription). An agent can distinguish it from create_webhook, list_webhooks, rotate_webhook_secret, and replay_webhook_delivery by the verb alone, though no sibling is named 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?
Usage is implied by the operation verbs but never stated: there is no 'use this when...' guidance, no mention of prerequisites, and no routing to alternatives such as rotate_webhook_secret or send_webhook_test. Adequate only at the minimum-viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read deterministic adapter provenance, cadence, and ingestion bounds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 and determinism profile is fully covered structurally. The description's word 'deterministic' mildly reinforces that, but adds no new behavioral context such as freshness, caching, or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short, front-loaded sentence with no filler. It is efficient, though it is a bare fragment with no framing that would orient a reader unfamiliar with the domain vocabulary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining what is actually returned, and it does so only with three abstract nouns. Combined with zero parameters and a near-duplicate sibling, an agent cannot confidently predict the response or distinguish this call from evidence_sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter meaning is lost.
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?
It names a resource-adjacent concept ('adapter provenance, cadence, ingestion bounds') but the terminology is internal jargon rather than a plain statement of what the tool returns. It also fails to differentiate from the close sibling 'evidence_sources', leaving an agent unsure which of the two to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no conditions or prerequisites, and no mention of alternatives such as evidence_sources or evidence_status. The agent must infer the use case entirely from the abstract wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List current active public evidence sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 fully covered. The description adds a useful scope signal ('current active public' — implying inactive/private sources are excluded), but says nothing about pagination, ordering, or result shape.
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?
One front-loaded sentence with no filler or redundancy. It is efficient, though the terseness leaves several gaps that a slightly longer description could have closed at little cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should carry the burden of explaining what is returned, yet it does not. Combined with an undocumented limit parameter and an undifferentiated near-identical sibling, an agent lacks enough to call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'limit' parameter, so the description must compensate and does not. It never mentions that results are paginated, that limit defaults to 20, or that it caps at 50.
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 ('List') and resource ('current active public evidence sources'), with qualifiers that narrow scope. However, it never distinguishes itself from the very similar sibling 'evidence_source_registry', leaving the agent to guess which listing to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative. With 'evidence_source_registry', 'evidence_datasets', and 'evidence_products' all present as siblings, the description gives the agent nothing to route on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read product API availability and capability status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered. The description adds only the subject matter of the read (availability and capability), not behavioral traits like latency, auth requirements, or caching. Adequate but thin given the annotations carry the main burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the verb and resource front-loaded and no filler. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the full burden of explaining what comes back, and it only gestures at the return content ("availability and capability status"). For a simple zero-arg tool this is minimally sufficient, but the shape of the response is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies no inputs are needed for a global status read.
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 clear verb ("Read") and a specific resource ("product API availability and capability status"), so an agent knows this is a status/introspection endpoint. However, it does not distinguish itself from related siblings such as evidence_webhook_availability, evidence_products, or evidence_quota, leaving overlap ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus alternatives, nor any prerequisites or exclusions. The usage is only loosely implied by the word "status"; an agent must guess whether this is a health check, a capability probe, or a prerequisite for other calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public evidence, editorial, news, newsletter, and forum records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, which covers the safety profile fully. The description adds no behavioral context beyond that — no result ordering, coverage limits, pagination behavior, or auth requirements — so it earns little credit against the already-rich 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?
A single front-loaded sentence with zero filler and the search verb stated immediately. It is efficient, though arguably too terse for a tool with a 50-result cap and no sibling disambiguation.
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 2-parameter search tool with no output schema, the description omits output shape, pagination/cap behavior, and any distinction from the three nearby search siblings. It is incomplete relative to what an agent needs to pick and 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 0% and both parameters are undocumented: the 300-character query cap and the 1-50 limit/default 20 range are nowhere explained. The description adds no parameter meaning beyond what the raw schema types convey, leaving the limit semantics and query scope unexplained.
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 ('Search') and enumerates the resource scope (public evidence, editorial, news, newsletter, forum records), so an agent knows what it queries. However, it never explains what makes it 'universal' versus the sibling evidence_search or evidence_semantic_search, so 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?
There is no when-to-use guidance, no conditions or exclusions, and no mention of alternatives despite close siblings (evidence_search, evidence_semantic_search, evidence_search_entities) that an agent must choose between. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded authenticated usage ledger summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds two useful hints beyond that: 'bounded' (results are capped) and 'authenticated' (auth is required). It says nothing about pagination, ordering, or what a 'ledger' contains, so the added value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It is efficient, though the sparseness borders on under-specification rather than a model of tight-but-complete writing.
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, one-parameter tool with annotations covering safety, the description is minimally viable. However, it never explains what 'usage ledger summaries' actually contain or how they relate to quota/entitlement siblings, leaving the agent without enough to confidently pick this 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 0%: the lone 'limit' parameter has min/max/default but no documented meaning. The description's word 'bounded' vaguely gestures at the cap but never explains what is being limited or its default, so it only partially compensates for the coverage gap.
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 clear verb ('Read') and a specific resource ('usage ledger summaries'), and qualifies it with 'bounded authenticated', which tells the agent the scope and access requirements. It does not distinguish itself from plausible siblings like evidence_quota or evidence_entitlements, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no alternatives named, despite a crowded sibling set (evidence_quota, evidence_entitlements, evidence_benchmarks) that likely overlaps with usage reporting. The agent must infer selection criteria on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one stored public claim against version-bound citations.
| Name | Required | Description | Default |
|---|---|---|---|
| claimId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=false, openWorldHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partially covered. However, the description adds almost no behavioral context beyond the annotations: it does not explain what verification changes, whether a result is persisted, or what happens on failure, which matters because the operation is not read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. Every word contributes to stating the operation and its scope.
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 non-read-only tool with one undocumented parameter, no output schema, and many sibling tools, the description is too sparse. It states the core action but omits usage context, parameter sourcing, and enough behavioral detail for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single required claimId parameter, so the description must compensate. It implies that 'one stored public claim' is identified by the parameter, but gives no format, source, or example for claimId, adding little beyond the schema's type and length constraints.
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: verify one stored public claim against version-bound citations. It is more specific than a tautology and indicates scope ('one stored public claim'), but it does not explicitly distinguish itself from closely related siblings such as evidence_version_claims or evidence_claim_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description implies the tool is for verifying a stored claim, but that implication is minimal and leaves routing decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public claims cited to one evidence document version.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| documentVersionId | Yes |
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 adds that only public claims are returned and that they are cited to one document version, which is useful scoping context, but it does not disclose pagination, ordering, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It states the resource and scope immediately and is appropriately sized for a simple list 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?
For a simple read-only list tool with annotations covering safety and no output schema, the description adequately states what is listed. However, it omits pagination behavior (the limit parameter) and does not explain the return structure, leaving some gaps for an agent to infer from the schema alone.
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 compensate. It clarifies that documentVersionId targets an evidence document version, but it entirely omits the limit parameter—its default, maximum, and purpose—leaving one of two parameters 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?
States a specific verb (List) and resource (public claims cited to one evidence document version), which clearly identifies the operation. However, it does not explicitly differentiate itself from sibling tools like evidence_claim_timeline or evidence_verify_claim, so it falls short of the top score for sibling differentiation.
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 no indication of when to use this tool versus alternatives such as evidence_search or evidence_claim_timeline. It implies a basic use case (fetching claims for a version) but provides no explicit when/when-not guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read whether webhook creation is currently operator-enabled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds that the state is operator-controlled (not user-settable), which is useful context, but says nothing about caching, latency, or what a 'disabled' result should trigger.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the resource and condition are front-loaded so an agent can decide instantly.
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 describing the return value; it implies a boolean availability flag but never states the response shape or how to interpret it. For a trivial no-arg read with full annotation coverage this is adequate, but not 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?
Zero parameters and 100% schema coverage, so the baseline of 4 applies. There is nothing further the description could add about inputs.
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 ('Read') and a precise resource ('whether webhook creation is currently operator-enabled'), which clearly separates it from siblings like evidence_create_webhook, evidence_set_webhook_status, and evidence_webhook_health. It does not name an alternative explicitly, so it falls just short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies this is a precondition check (verify availability before attempting creation), but it never states when to call it or what to do if the flag is false. No alternatives or exclusions are named, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bounded health for one owner-scoped webhook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| subscriptionKey | Yes |
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 fully covered elsewhere. The description's only added behavioral content is the implicit owner-scoping and the vague "bounded" qualifier; it says nothing about what the health measurement covers or how it is capped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though it is terse to the point where important qualifiers ("bounded") go undefined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and an undocumented parameter, the description needed to say what "health" returns (delivery failures, retry state, uptime window) and how it differs from availability/history. It does none of that, so an agent cannot predict the response or validate its choice of 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 0%, so the description must carry the param. It does convey that subscriptionKey identifies a single subscription and that resolution is limited to the caller's owner scope, which is real added meaning, but it gives no format, derivation, or example for the key.
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?
It pairs a clear verb ("Read") with a specific resource ("health for one owner-scoped webhook subscription"), so the basic action is recoverable. But "bounded health" is unexplained jargon and the description never distinguishes this from nearby siblings such as evidence_webhook_availability or evidence_webhook_history, leaving the agent unsure which health view it gets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. With three other webhook-read siblings in the toolset, the absence of any routing hint means the agent must guess between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bounded recent deliveries for one webhook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| subscriptionKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds that results are 'bounded' and 'recent', signaling truncated, recency-limited output rather than full history – useful context, but it stops short of stating ordering, pagination, or a window definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler; every word ('bounded', 'recent', 'one', 'deliveries') carries meaning. No restructuring would improve it.
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 bounded-list tool whose annotations cover safety and which has no output schema, the description covers the core. But an agent still lacks ordering (newest-first?), what a 'delivery' record contains, and how 'bounded' relates to the limit parameter, leaving the definition adequate rather than 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 0%, so the description must carry parameter meaning. 'one webhook subscription' implies the required subscriptionKey, and 'bounded recent' gestures at the limit parameter, but neither default (20), maximum (50), nor the key's format/length constraints are explained. It partially compensates but leaves real gaps.
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 'List' and resource 'deliveries' scoped to 'one webhook subscription', which distinguishes it from sibling list_webhooks (webhooks, not deliveries) and from webhook_health/availability. It does not explicitly name a sibling, but the verb+resource pairing is precise enough that an agent can differentiate.
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 'recent deliveries for one webhook subscription' – an agent infers this is for inspecting delivery history. However there is no explicit when-to-use, no contrast with webhook_health or webhook_availability, and no stated prerequisites (e.g., that a valid subscription key is required).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
evidence_benchmarksevidence_changesevidence_claim_timelineevidence_create_exportevidence_create_researchevidence_create_webhookevidence_datasetsevidence_documentevidence_entitlementsevidence_get_exportevidence_get_export_artifactevidence_get_export_manifestevidence_get_researchevidence_get_research_artifactevidence_list_webhooksevidence_productsevidence_quotaevidence_replay_webhook_deliveryevidence_rotate_webhook_secretevidence_searchevidence_search_entitiesevidence_semantic_searchevidence_send_webhook_testevidence_set_webhook_statusevidence_source_registryevidence_sourcesevidence_statusevidence_universal_searchevidence_usageevidence_verify_claimevidence_version_claimsevidence_webhook_availabilityevidence_webhook_healthevidence_webhook_historyEvidence-bearing public webpage monitoring with hashes, diffs, signed webhooks, REST, and MCP.
OFAC, FDA, federal award and Federal Register lookups with signed machine evidence.
Official EUR-Lex, UK, US, and gazette search, metadata fetch, and change-only watches.
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
