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

No annotations are present, so the description carries the full burden of behavioral disclosure. It lists the data source categories but does not clarify key behaviors such as whether the tool performs external network calls, how results are aggregated, whether it is read-only, or what the output format looks like. This is a significant transparency gap for an analysis tool.

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

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

The description is a single sentence, front-loaded with the action and resource, and lists sources compactly without unnecessary words. It is appropriately sized for what it communicates, though it omits deeper context that would improve usefulness.

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

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

Given the absence of annotations and output schema, plus the existence of several related siblings, the description is under-specified. It does not explain what 'analyze' produces, how the tool relates to other analysis tools, or any operational caveats. An agent cannot confidently predict the tool's behavior or output from this description 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 100%, so both parameters are already documented in the schema. The description adds no additional parameter-level context beyond what 'domain' and 'entity_id' already state. A baseline of 3 is appropriate because the schema handles parameter documentation adequately.

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 clearly states the action ('Analyze') and the resource ('an entity digital footprint'), and enumerates the sources covered (official, GitHub, package registry, documentation, 3rd-party). This distinguishes it from generic search/get siblings, though it doesn't explicitly differentiate from audit_entity_consistency or find_evidence, which could overlap.

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 invoke this tool versus sibling tools such as find_evidence, get_entity, or audit_entity_consistency. The description implies a general analysis use case but provides no context, prerequisites, or exclusions.

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

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

No annotations are provided, so the description must disclose behavior. 'Diagnostic audit' hints at a read-only operation, but it never states whether the tool mutates state, fetches external data, has side effects/rate limits, or what kind of report it returns.

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?

Single sentence, front-loaded with 'Diagnostic audit', and compresses the scope into a compact list. 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?

Because there is no output schema, the agent is not told what the audit returns (report object? list of mismatches? pass/fail?). Combined with no annotations and no behavioral caveats, the description leaves important operational details missing for a one-parameter diagnostic 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?

Entity_id is already documented as canonical ID/name in the schema, and schema coverage is 100%. The description's list of audit dimensions adds context to what consistency means but doesn't explain parameter format or special values beyond the schema; baseline 3 applies.

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

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

Description identifies a specific action ('audit') and object ('entity consistency'), listing the data sources checked (company name, domains, GitHub orgs, npm scopes, Schema.org markup). This is enough to distinguish it from search/get/verify siblings, though it does not explicitly contrast with analyze_web_presence.

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 'diagnostic audit' implies use when the user wants to check consistency, but there is no explicit when-to-use, when-not-to-use, or alternative routing. Siblings like analyze_web_presence could plausibly overlap, and the description doesn't disambiguate.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the core action (comparing claims and exposing discrepancies) and a methodological stance ('without arbitrary bias'), but it does not state whether the operation is read-only, what the exact output format is, or how discrepancies are determined. Some behavioral context is present, but significant gaps remain.

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 sentence that opens with the key verb 'Compare' and concisely states the action and intended outcome. There is no redundant or filler content; every word contributes to understanding the tool's purpose.

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's interface is simple (one required array parameter), and the description covers its main function. However, since there is no output schema, the description should clarify the structure of the returned 'discrepancies' (e.g., list, report, boolean). It also omits edge-case behavior such as handling empty claims lists or claims with no conflicts. The description is adequate but leaves room for interpretation.

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

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

The input schema already describes the sole required parameter `claims` as 'List of claim statements to compare', giving 100% coverage. The description adds the nuance that the claims should be 'potentially conflicting', but it does not add any format, constraint, or usage details beyond what the schema provides. This aligns with the baseline score of 3 for high schema coverage.

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 ('Compare'), a clear resource ('multiple potentially conflicting claims'), and a concrete outcome ('expose discrepancies'). It naturally distinguishes compare_claims from sibling tools like verify_claim (single-claim verification) and trace_claim (source tracing) by focusing on cross-claim comparison. The purpose is unambiguous.

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 implies the tool should be used when multiple potentially conflicting claims need to be compared, providing an implicit usage context. However, it does not explicitly state when to prefer this tool over alternatives such as verify_claim or audit_entity_consistency, nor does it mention any exclusions or prerequisite conditions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does convey that the output will be concise, factual, sourced from verified sources, and include structured relationships, which gives some sense of behavior. However, it does not mention what happens for unknown entity IDs, whether sources are returned inline, or any limitations of the explanation.

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. Every qualifier—concise, factual, verified sources, structured relationships—adds meaningful information about the return value.

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 tool with no output schema, the description provides a reasonable high-level summary. However, it lacks return-field detail and does not clarify how it differs from get_entity, which is a notable gap given the large sibling set.

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

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

The input schema already documents entity_id as 'Canonical entity ID or recognized name' with 100% coverage. The description adds no parameter-specific semantic meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Return') and clearly identifies the resource: a concise, factual entity profile backed by verified sources and structured relationships. It differentiates the output from a raw entity lookup, but it does not explicitly distinguish itself from the sibling get_entity, so it is clear but not fully differentiated.

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 guidance on when to use explain_entity instead of get_entity, find_relationships, or verify_claim. It also provides no exclusions or context that would help an agent select this tool over the many closely related siblings.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action but does not disclose the return value or output type (e.g., whether it returns a file, string, or URL), nor any side effects, permissions, or limitations. This is a significant gap for a tool that exports data.

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 redundancy. It states the action and the relevant formats efficiently, with no wasted words.

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 has no output schema, so the description should explain what the agent receives upon invocation. It does not mention the return type, file handling, or any constraints. Given the tool's simplicity, the description is incomplete for an agent to predict the outcome of the call.

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 already documents the single 'format' parameter with an enum and a description, so coverage is 100%. The description repeats the same format list and adds minimal context by calling them 'standard interoperable formats', but it does not explain nuances or selection criteria between formats, so it adds little beyond the schema.

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

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

The description clearly states the action (export) and the resource (verified knowledge graph), and lists specific target formats (JSON, JSON-LD, CSV, GraphML). It is distinct from all sibling tools, which focus on searching, verifying, and analyzing individual entities or claims, not on exporting the entire graph.

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 implies the use case: when you need the graph in an interoperable format. It does not explicitly contrast with alternatives or state when not to use it, but the sibling tools are all about entity-level operations, so the distinction is clear and the context is unambiguous.

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

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

Annotations are absent, so the description carries full behavioral burden. It does disclose that output is compact, ranked, and budget-limited, but it does not explain ranking criteria, possible failure modes, or what form the evidence takes. This is more than a tautology but still leaves meaningful behavior undocumented.

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 tightly written sentence. It front-loads the action and outcome and contains no filler or redundant restatement of the tool 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 two-parameter tool, the description captures the core contract, but with no output schema it leaves the exact return shape and ranking semantics underspecified. Given siblings like get_evidence_packet, more explicit output expectations would improve completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The prose reinforces both 'claim' and 'token budget' but adds no new parameter semantics beyond what the schema already states, such as allowed max_tokens values.

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

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

The description names a specific verb ('Retrieve'), a resource ('supporting evidence for a claim'), and the output style ('compact, ranked'). The 'strict token budget' further distinguishes it from sibling tools like get_evidence_packet or verify_claim, making the tool's role clear.

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

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

The phrase 'under a strict token budget' implies a budget-constrained evidence-retrieval use case, but there is no explicit guidance on when to prefer this over siblings such as verify_claim or get_evidence_packet. No alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but omits any side effects, authentication requirements, rate limits, or limitations. It also doesn't clarify whether this is a read-only operation, though 'discover' suggests it. For a graph traversal tool, the lack of detail on output format, pagination, or performance implications leaves significant behavioral gaps.

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 redundant words. It immediately conveys the core functionality and the key scope (depth and entity). Every word earns its place, and the structure is optimal for quick scanning by an agent.

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 explain what the tool returns in terms of structure and content. It mentions 'connecting graph paths' but doesn't specify the format (e.g., list of nodes, edges, or a graph object) or what happens when no relationships are found. It also doesn't clarify how depth affects the result beyond a simple traversal. For a tool with this complexity, the description is insufficient for an agent to fully predict the tool's behavior.

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

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

Schema description coverage is 100%, so all parameters (depth, entity_id, relationship) are already documented in the input schema. The description adds minimal extra meaning beyond the schema, mainly reinforcing that the tool discovers relationships and paths. Since the schema does the heavy lifting, the baseline of 3 applies, and the description doesn't significantly enhance parameter understanding.

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 clearly states the action ('Discover') and the resource ('1-hop, 2-hop, or 3-hop relationships and connecting graph paths'), anchored on a starting entity. It distinguishes itself from sibling tools like get_entity (single entity) and search_entities (search) by focusing on multi-hop relationship discovery. The verb-resource pair is specific and unambiguous.

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 implies when to use it ('starting from an entity') and its purpose (relationship discovery), but it does not explicitly mention alternatives or exclusion criteria. With many siblings like trace_claim and compare_claims, an agent might infer this is for general relationship exploration, but there's no direct guidance on when not to use it or which sibling to choose instead. The usage context is clear but not explicit.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the operation is a read-only retrieval and names the categories of data returned, which is useful; however, it does not describe output shape, failure behavior, or whether relationships are resolved recursively.

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. Every phrase ('canonical information, aliases, metadata, connected relationships') earns its place by communicating 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?

The tool is simple (one required parameter) and the description plus schema are enough for basic invocation. However, there is no output schema and no mention of response format or edge-case behavior, and the overlap with sibling tools is left unresolved.

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

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

Schema coverage is 100%: entity_id is defined with an example and required flag. The description adds no parameter semantics beyond the schema, so it stays at the baseline 3.

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

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

The description uses a specific verb ('Retrieve') plus the resource ('canonical information, aliases, metadata, and connected relationships') for a given entity ID, so an agent can tell this is a point lookup. It does not explicitly distinguish itself from find_relationships or explain_entity, which may also surface relationship/entity detail, so it loses the sibling-differentiation point.

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 is given about when to choose get_entity over search_entities or find_relationships. The phrase 'specific entity ID' hints that the caller must already have an ID, but no exclusions or alternative routing are stated.

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

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

With no annotations provided, the description carries the behavioral burden. It does disclose a meaningful trait: the tool returns the 'smallest verified' packet, signaling minimization and verification. But it does not describe what happens when no question, claim, or entity is provided, what an evidence packet contains, or any operational constraints.

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 communicates the tool's role and key behavioral promise with no wasted words. The main purpose is stated first, followed by the defining constraint.

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

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

The description is adequate for a first-pass retrieval interface, but it lacks context around how this tool relates to the many siblings and how the optional parameters compose. Since there is no output schema, more detail about what an 'evidence packet' contains would help the agent invoke 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 coverage is 100%, so the schema already documents all four parameters. The description adds only the conceptual framing that the packet answers a question, but it does not deepen parameter meaning beyond what the input schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('returns') plus a concrete resource ('smallest verified evidence packet') and condition ('sufficient to answer a question'). It clearly conveys what the tool does, and 'Primary AI agent retrieval interface' helps set it apart from the sibling search and verification tools, though it does not explicitly name a distinguishing alternative.

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?

'Primary AI agent retrieval interface' gives clear context that this should be the first retrieval tool an agent reaches for. However, it does not explicitly state when to use alternatives like find_evidence, verify_claim, or get_entity, nor does it state exclusions.

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

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

With no annotations, the description must carry behavioral disclosure. It reveals that matching is multi-signal and that results are candidate entities, implying fuzzy or ranked rather than exact lookup. It doesn't describe result ordering, pagination, or edge cases, so coverage is partial.

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?

Single sentence front-loads the verb and object, then adds scoping detail. No filler; 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 simple two-parameter search tool, the core invocation is clear. However, the absence of an output schema means the description should have said what the returned candidates look like or how matching behaves, and it doesn't address when to prefer get_entity. This leaves the agent to infer integration 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?

Input schema covers both parameters fully, so the description adds little new parameter meaning. The phrase 'name, alias, or keyword' mirrors the query schema's description, and limit behavior is documented only in the schema.

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

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

Description names a concrete operation—searching candidate entities—and scopes it by input type (name, alias, keyword) and method (multi-signal matching). This distinguishes it from exact-lookup siblings like get_entity and from relationship/evidence tools.

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

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

The description establishes clear trigger conditions: an agent should call this when it has a name, alias, or keyword and needs candidate entity matches. It doesn't explicitly state when not to use it or name an alternative, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully enumerates the chain stages and implies a read-style trace operation, but it does not state whether the tool has side effects, how results are returned, whether the chain is guaranteed complete, or what happens when evidence is missing.

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 that packs in the operation, the resource, and the expected chain components without filler. Every part 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 simple two-parameter tool, the description conveys the essential purpose. However, with no output schema and no annotation context, an agent still lacks information about return format, error behavior, and how this tool relates to overlapping siblings, so the context 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?

Schema description coverage is 100%, so the parameters are already documented. The description adds little beyond labeling the operation as claim-based tracing; entity_id remains only 'Optional entity ID' with no explanation of how it disambiguates or affects the trace.

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

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

The description uses a specific verb ('Trace') and resource ('claim'), and it defines the output scope as a provenance chain through Evidence, Source, URL, Timestamp, and Hash. This is clearly distinct from a generic search or entity lookup, though it does not explicitly name or differentiate from sibling tools such as verify_claim.

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 intended use is implied: call this when you need the complete provenance chain for a claim. However, the description does not state when to prefer this over siblings like verify_claim, find_evidence, or get_evidence_packet, and it provides no explicit exclusions or alternative conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool verifies claims but does not disclose whether it is read-only, what side effects might occur, what output format to expect (e.g., boolean, evidence summary), or any rate limits or access constraints. The mention of 'cryptographic, timestamped evidence sources' hints at the underlying mechanism but lacks concrete behavioral detail.

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, well-structured sentence that front-loads the purpose. It is concise with zero filler, making it easy for an agent to quickly grasp the tool's core function. The brevity is appropriate for the tool's simplicity.

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

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

Given the tool's moderate complexity (2 parameters, no output schema), the description is incomplete. It does not specify what the tool returns (e.g., a boolean, a confidence score, or evidence details), nor does it explain how the 'cryptographic, timestamped evidence sources' are accessed or what criteria constitute verification. Agents would lack critical information to interpret results and handle edge cases, especially since 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?

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal extra meaning: it mentions the claim as the core subject and implies that entity_id is optional for scoping, but it doesn't elaborate on how entity_id affects the verification process or provide format examples beyond the schema. This is adequate but not enhancing.

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 clearly states the tool's purpose: verifying an assertion or claim against evidence sources. The verb 'verify' is specific, the resource is identified as 'assertion or claim', and it distinguishes itself from siblings like trace_claim or compare_claims by focusing on cryptographic and timestamped evidence. This is not a tautology and provides a clear, unique function.

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 offers no guidance on when to use this tool versus its siblings. It doesn't mention alternatives like trace_claim, compare_claims, or find_evidence, nor does it specify conditions that would favor one tool over another. The only implicit context is that verification is needed, but no exclusions or comparisons are provided.

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