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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a signed receipt JCS and sha256, implying the action is recorded and irrefutable. However, it does not specify whether the approval is reversible, what permissions are required, or what happens on failure. Some behavioral 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 directly states the action and the return value. There is no extraneous information; every word is necessary and front-loaded.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description is sufficient. It mentions the key outputs (signed receipt JCS and sha256), which complements the output schema. However, it could briefly note that the approval must be pending, which is implied but not explicit.

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

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

Schema coverage is 100%, so the baseline is 3. The tool description does not add information about the parameter beyond what is in the schema's description for 'approval_id' (which references 'approval.approval_id'). The description does not provide format constraints or additional semantics, so no uplift.

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 approves a pending human approval request and returns a signed receipt JCS plus sha256. The verb 'approve' is specific and the resource is a human approval request, distinguishing it from sibling tools like 'deny_action' which performs the opposite action.

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 provides clear context for when to use this tool: to approve a pending request. It implicitly distinguishes from 'deny_action', but does not explicitly state when not to use it or suggest alternatives like first retrieving the request via 'get_approval_request'. However, the purpose is clear enough for an agent to decide.

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?

States 'Read-only. Does not modify any data or affect the target agent's score.' Since no annotations are provided, the description fully covers behavioral traits, making it clear this is a safe query 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?

Well-structured with clear sections: purpose, usage guidance, safety note, parameter description, and return format. Every sentence is informative and earns its place without redundancy.

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 simplicity (one required parameter, output schema exists), the description covers all essential aspects: what it does, when to use it, alternatives, behavioral impact, and return structure. It is fully complete for an agent to use 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?

Input schema already describes the 'did' parameter completely (100% coverage), including the required format. The description's Args section repeats the same information without adding new semantics or constraints beyond what the schema provides.

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

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

Description clearly states 'Get the full reputation profile of an agent' and enumerates return components (score, confidence, risk factors, tier). It differentiates from siblings by specifying this is for numerical data, not yes/no decisions (check_trust) or rating history (get_attestations_received).

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

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

Explicitly tells when to use ('when you need the actual numbers') and when not to, with specific alternative tools named ('NOT for yes/no delegation decisions — use check_trust instead', 'NOT for rating history — use get_attestations_received'). This is excellent 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?

No annotations provided, so the description carries full burden. It states 'Read-only. Does not modify any data' and 'Advisory signal, not a guarantee', and explains tier ordering. However, it does not mention error behavior, potential logging, or state changes beyond read-only, leaving minor 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?

Extremely concise: opens with core purpose, then usage guidelines, tier info, read-only note, and parameter/return sections. Every sentence adds value. No redundancy or 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?

Given the output schema exists (described in Returns), the description covers purpose, usage, parameters, behavior, and return structure. It lacks error handling or rate limit info, but for a simple check tool, this is nearly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds tier ordering context, default value for min_tier, and examples for task_type. It also describes the return format (JSON with allowed, score, tier, risk_level, reason), going 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 it provides a 'Quick yes/no delegation decision' and returns 'allowed (true/false) with a human-readable reason'. It distinguishes from siblings by noting 'NOT for detailed analysis — use check_reputation' and 'NOT for rating history — use get_attestations_received', making the purpose 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?

Explicitly says 'Use this when you only need a go/no-go answer before delegating work' and provides clear exclusion criteria with specific alternative tool names. This is textbook usage 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?

No annotations provided, but description covers return format (JSON string), possible statuses, and the need for a follow-up call. Doesn't address rate limits or auth, but sufficient for basic behavior.

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

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

Four sentences, front-loaded with purpose, concise and 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?

Given 8 params, 100% schema coverage, and existence of output schema, the description explains the flow, statuses, and follow-up. Still some room for more detail on return format.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no extra parameter details beyond the schema, but provides overall context for delegation_receipt and params.

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 it runs the 'controlled-action flow,' specifies the return format and possible statuses, and distinguishes from siblings like execute_after_approval.

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

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

Explicit guidance: human approval is never auto-approved, and after approval call execute_after_approval. Provides clear context for when to use this tool versus its sibling.

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 indicates the tool mutates state (denying a request) and returns a receipt, but it does not disclose side effects, required permissions, irreversibility, or error conditions. The description is insufficient for an agent to fully understand the tool's behavior.

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

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

The description is a single sentence that front-loads the main action and return values. It is concise and contains no filler, though it could be slightly more structured by separating action from return value details. It efficiently communicates the core 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?

Given the tool has an output schema and relatively simple semantics, the description is moderately complete. It covers the action and return values, but it does not explain how this tool fits into a workflow with siblings like 'approve_action' or 'controlled_action', nor does it clarify what 'pending' implies about the request's state.

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

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

The input schema has 100% description coverage, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides. According to the guidelines, with high schema coverage, a baseline of 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 clearly states the action ('Deny') and the resource ('pending human approval request'), and specifies the return value ('signed receipt JCS plus sha256'). This distinguishes it from its sibling 'approve_action' and provides a clear, specific 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?

The description implies the tool is for denying a pending request, which provides basic context. However, it lacks explicit guidance on when to use it versus alternatives, prerequisites, or conditions like whether the request must be in a specific state. The phrase 'pending' hints at the context but is not detailed enough.

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 provided, so description carries full burden. It only mentions passing through the approval key, omitting side effects, error conditions, or idempotency. Minimal 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?

Two short, direct sentences with no fluff. Purpose is front-loaded and every word adds 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?

Despite an output schema being present, the description fails to explain what the tool returns or any execution context. Lacks guidance on error handling or confirmation of success.

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 has 100% coverage with descriptions for all 6 parameters, so description adds negligible value. 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?

Clearly states it resumes a controlled action after approval, referencing the approval payload key. Distinguishes itself from siblings like 'approve_action' or 'controlled_action' by specifying the resume behavior.

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?

Implies usage for resuming after approval but lacks explicit when-to-use vs. alternatives or exclusions. No mention of when not to use or prerequisites.

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?

Without annotations, the description directly states 'Read-only — does not affect reputation or any stored data,' which fully discloses the non-destructive nature. It also explains the return format and error case, providing complete behavioral context.

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 well-structured into clear sections: purpose, usage guidance, alternatives, behavioral note, parameters, and return values. Every sentence adds value, no fluff, and it is appropriately concise 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 simplicity (1 parameter, no annotations, no output schema but returns described), the description is fully complete. It covers when to use, what it does, behavioral impact, parameter details, return format, and error handling.

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% with a basic description for 'did'. The description adds meaningful context: format requirement ('did:key:z6Mk...') and validation condition ('Must be a registered agent on the AVP network'), improving over the schema alone.

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: 'Get public profile information about a registered AI agent.' It specifies the verb 'Get' and the resource 'public profile information', distinguishing it from siblings by listing alternatives for other needs.

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 explicitly says 'Use this when you already have a specific DID and need profile data.' It also provides clear when-not-to-use guidance and names specific sibling tools (check_reputation, get_attestations_received, search_agents) for alternative actions.

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 fully convey behavior. It only states it fetches a request visible to the local agent identity, but omits details like whether the request is removed after fetching, permissions needed, or any side effects.

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, concise sentence that front-loads the key information. No filler or redundancy.

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 fetch tool with an output schema, the description is somewhat complete but lacks usage guidance. It does not explain what the return object contains, though the output schema may cover that.

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% with a well-described parameter (approval_id). The description does not add extra meaning beyond the schema, but per guidelines, baseline is 3 for high 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 clearly states the specific action (fetch) and resource (human approval request), and distinguishes it from sibling tools like approve_action or deny_action which modify approvals.

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 tool versus siblings (e.g., approve_action, execute_after_approval). The description provides no context about typical use cases or prerequisites.

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?

The description states 'Read-only. Does not affect reputation or stored data', which is a key behavioral trait. Since no annotations were provided, the description fully covers the safety profile and ordering ('newest first').

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 well-structured with clear sections: purpose, what is returned, exclusions and alternatives, read-only note, arguments, and returns. Every sentence adds value, and it is appropriately concise.

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 output schema exists (context signals indicate has output schema), the description still explains return fields (from_agent_did, outcome, weight, context, created_at) and ordering. It covers purpose, usage, behavior, and parameter fully.

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 'did' parameter with 100% coverage. The description's 'Args' section adds a format example ('did:key:z6Mk...') and context, providing useful but not essential extra meaning 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 it gets peer ratings (attestations) received by an agent and explains what is returned (individual ratings with who gave them, outcome, weight, context). It differentiates from siblings by explicitly saying what it is NOT for and naming alternative tools (get_audit_trail, check_reputation).

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 explicit when-to-use ('Use this to understand the evidence behind a score') and when-not-to-use ('NOT for protocol-level events... NOT for the computed score') with direct references to alternative tools (get_audit_trail, check_reputation).

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. It discloses read-only nature, public data, no authentication, and return format. Minor deduction for not mentioning potential rate limits or error handling.

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?

Well-structured with clear sections: purpose, details, usage, differentiation, parameters. Every sentence adds value, no redundancy.

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 output schema exists, the description sufficiently summarizes return values and covers all essential aspects: purpose, parameters, usage context, and sibling differentiation.

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%, baseline 3. Description adds format hints (did:key:z6Mk...), ordering (newest first), and explicit range for limit, increasing clarity beyond 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 uses a specific verb-resource pair ('Get the tamper-evident audit trail') and clearly distinguishes from siblings like get_attestations_received and verify_audit_chain.

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

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

Explicitly states when to use (compliance, due diligence, dispute evidence) and provides direct alternatives for peer ratings and chain integrity checks.

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 fully convey behavior. It only states what is fetched, not side effects, authentication needs, error conditions, or whether it is read-only. As a fetch operation, it is presumably safe, but this is not explicitly stated.

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 concise sentence with no unnecessary words. All information is front-loaded.

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

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

For a simple tool with one required parameter and an existing output schema, the description is nearly complete. It could briefly explain the purpose of the sha256 digest or the JCS text, but the context of sibling tools makes the function clear.

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%—the parameter 'audit_id' is described as 'Runtime Gate audit_id whose signed DecisionReceipt should be fetched'. The tool description adds no new semantics beyond restating the resource. 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?

Description clearly states the action ('Fetch') and specific resource ('exact signed DecisionReceipt JCS text and its sha256 digest'). Differentiates from sibling tools like get_execution_receipt and get_audit_trail by specifying 'DecisionReceipt'.

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 tool versus alternatives (e.g., get_execution_receipt, verify_audit_chain). Does not mention prerequisites or context such as after an approval action.

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?

The description indicates a read operation ('Fetch') but does not disclose error handling, rate limits, or permission requirements. With no annotations, behavioral transparency is moderate; it confirms the output includes text and a digest, but lacks depth.

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, focused sentence of 12 words. It is front-loaded with the action verb and delivers essential information without any redundant or extraneous 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 simple read tool with one parameter and an output schema, the description is largely complete. It states what is fetched and the digest aspect. However, it omits any mention of required preconditions or error states, which slightly reduces 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?

The input schema already fully describes the single parameter ('receipt_id') with a clear description. The tool description adds no additional meaning beyond what the schema provides, 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 clearly states the action ('Fetch') and the specific resource ('signed ExecutionReceipt JCS text and its sha256 digest'), which is precise and unambiguous. It distinguishes itself from sibling tools like 'get_decision_receipt' by specifying the exact receipt type and output format.

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 provided on when to use this tool versus alternatives like 'get_decision_receipt' or 'get_approval_request'. There are no usage notes, prerequisites, or conditions specified, leaving the agent to infer context solely from the name.

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?

Discloses that it returns private details, is read-only, depends on environment variable AVP_AGENT_NAME, and provides full return format. No annotations provided, but description carries the burden well.

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?

Well-organized with clear sections. A bit verbose but each sentence adds value. Could potentially be condensed slightly.

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?

Complete for a zero-parameter tool with output schema. Covers purpose, usage, behavior, return format, and contrasts with siblings.

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?

No parameters exist, so description cannot add parameter-specific semantics. However, it explains why no parameters are needed (uses configured agent). Schema coverage is 100%.

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?

Clearly states it retrieves the locally configured agent's DID, registration status, and reputation. Explicitly distinguishes from sibling tools like get_agent_info and check_reputation.

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?

Provides explicit instructions on when to call (before submit_attestation or publish_agent_card) and when not to (for other agents, use get_agent_info or check_reputation). Includes alternative tool names.

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 discloses 'Read-only. No authentication required. No parameters.' and that it returns counts, not individual data. No contradictions, but could mention rate limits or side effects (though none expected).

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 concise, well-structured with clear sections: purpose, usage, exclusions, behavioral traits, and return format. Every sentence adds 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?

Given the tool's simplicity (no params, output schema exists), the description fully explains what it does, when to use, and what it returns. No 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?

No parameters (0 params) per schema. The description states 'No parameters' which aligns with schema. Baseline 4 per rule for 0 params.

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 it gets 'network-wide aggregate statistics' and distinguishes from siblings like check_reputation for individual agents and search_agents for finding by capability.

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

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

Explicitly says when to use: to answer 'how big is the AVP network?' or 'is the service active?' before registering an agent. Also states when not to use and provides alternative tools.

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 fully discloses behavioral traits: idempotent ('calling it again replaces the previous card entirely'), visibility ('publicly visible to all agents on the network immediately'), prerequisites ('Requires a registered agent identity'), side effects ('creates or replaces your public capability card. No effect on other agents.'), and error conditions ('Returns error if not registered or on invalid input'). Meets all transparency needs.

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 appropriately concise (~10 lines) and well-structured: a one-line purpose, followed by discovery benefit, important note, prerequisites, side effects, arguments section, and return value. Every sentence adds value, and key information is front-loaded. No unnecessary repetition or 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?

Given the tool's moderate complexity (3 parameters, 1 required) and the presence of an output schema (described in Returns), the description covers all necessary context: prerequisite steps, behavioral guarantees (idempotent, public visibility), side effects, error cases, and post-use verification. It sufficiently enables an agent to decide when and how to invoke this tool correctly relative to siblings.

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 description adds minimal value beyond schema. The Args section largely restates schema descriptions (e.g., 'Comma-separated capabilities. At least one required. Examples: ...'). The description provides example values for capabilities and endpoint_url, which adds slight clarity, but does not introduce new semantic constraints or clarify interdependencies. Therefore, a score of 3 is appropriate (baseline 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 clearly states the tool's purpose: 'Publish or update your agent's capability card for network discovery.' It specifies the verb (publish/update) and resource (capability card). It also distinguishes from sibling tools like register_agent (registration prerequisite) and search_agents (post-publication verification), making its unique role explicit.

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?

Provides explicit prerequisites: 'Requires a registered agent identity (call register_agent first).' Advises on post-use verification: 'Use search_agents afterward to verify your card is discoverable. Use get_my_agent_info to check your current registration status.' Also clarifies when not to use by implication (requires registration, idempotent so safe to repeat). No contradictory 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 fully discloses side effects (local key file with chmod 0600, network registration), irreversibility, and key regeneration impossibility. This goes well beyond basic purpose.

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?

Description is well-structured, front-loading purpose, then details, usage, and side effects. Every sentence adds value without redundancy.

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 complexity (identity creation, network registration), the description covers setup prerequisites, side effects, return format, and failure cases. Output schema complements but description is self-sufficient.

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 covers the single parameter with description and default. The description repeats the parameter details and environment variable fallback, adding marginal value beyond 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 clearly states the tool registers a new AI agent on the Agent Veil Protocol network, detailing the cryptographic identity and DID creation. It distinguishes from sibling tools by positioning it as a one-time setup before write operations.

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

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

Explicitly advises calling once before write operations and suggests using get_my_agent_info to verify setup. While it doesn't list when not to use, the context of first-time setup and permanence is clear.

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 full burden. It discloses the tool is read-only (evaluates, does not execute) and the expected decision values. It does not mention side effects, auth needs, or rate limits, but the overall behavior is transparent enough.

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

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

Three sentences, front-loaded with the core purpose, and every sentence adds necessary context. No redundant 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?

Given there is an output schema (not shown but indicated), the description sufficiently covers the tool's purpose, scope, and decision outcomes. It could mention prerequisites like delegation receipt, but the required parameters already imply that.

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 coverage is 100%, so baseline is 3. The description adds value by explaining the overall purpose and that the tool returns a decision payload, but it does not elaborate on individual parameters beyond the schema. Still, the schema descriptions are clear, so the combined effect is good.

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 evaluates one proposed action with AVP Runtime Gate and returns a decision (ALLOW, WAITING_FOR_HUMAN_APPROVAL, BLOCK). It distinguishes itself from executing actions, which separates it from sibling tools like execute_after_approval.

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 explicitly states the tool only evaluates, does not execute, and does not intercept other calls, giving clear context for when to use it. However, it lacks explicit when-not-to-use guidance or naming of alternative tools like approve_action or execute_after_approval.

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?

States 'Read-only — does not modify any data.' and 'Results are sorted by reputation score (highest first).' This adds value beyond schema, though could mention more about execution context.

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?

Well-structured: headline, usage context, sorting, read-only note, then parameter and return descriptions. No fluff, front-loaded.

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

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

With output schema present, description still details return fields. Covers all parameters, differentiates from siblings, and provides enough for a search 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?

Despite 100% schema coverage, description adds examples for capability and provider (e.g., 'code_review', 'anthropic') and explains min_reputation with a practical suggestion ('Set 0.5+ to exclude unproven agents'). Enriches understanding beyond 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 'Find AI agents by capability, provider, or minimum reputation score.' It specifies the verb (Find) and resource (AI agents), and distinguishes from siblings like get_agent_info and check_reputation.

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

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

Explicitly tells when to use: 'Use this to discover available agents for a task before delegation.' Provides alternatives: 'Use get_agent_info when you already have a specific DID. Use check_reputation or check_trust to evaluate a found agent.'

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. It discloses immutability, cryptographic signing, side effects (permanently modifies history and reputation), blocked self-attestation, requirement for prior registration, and potential error responses. This is comprehensive for a tool with no 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?

The description is well-structured with clear sections: summary, importance caveat, side effects, prerequisites, blocked actions, bulleted argument list, and return value specification. It is concise yet complete, with no unnecessary 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?

Given 4 parameters, 100% schema coverage, presence of output schema (described), and 19 sibling tools, the description covers all needed aspects: purpose, usage constraints, side effects, prerequisites, error handling, and return format. It is fully informative for agent invocation.

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

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

Schema coverage is 100%, but the description adds significant value: for 'outcome' it repeats allowed values; for 'weight' clarifies confidence impact; for 'context' provides examples; and it documents return values and error cases not in the schema. This goes beyond the schema's basic descriptions.

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

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

The description clearly states 'Submit a peer attestation (rating) for another agent after an interaction.' It uses a specific verb (submit) and resource (attestation), and distinguishes from sibling tools like check_reputation and get_attestations_received by explaining its role as the primary reputation-building mechanism.

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 explicitly says to use this after an interaction and warns against self-attestation. It implies the dispute system for contesting ratings but does not explicitly name alternative tools for specific cases (e.g., reading reputation). This is clear context but lacks explicit exclusions for all alternatives.

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?

Despite no annotations, the description fully discloses behavior: read-only, no authentication required, safe to call anytime. It explains what the tool checks (SHA-256 hash chain) and describes return values including possible error cases.

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 concise, well-structured, and front-loaded. Each sentence adds value, covering purpose, mechanism, usage, safety, and return format without redundancy.

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 parameterless tool with an output schema, the description is complete. It explains the return values and error handling, and covers behavioral context. No gaps remain.

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

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

The input schema has zero parameters and 100% coverage, so the description needs to add no param info. Baseline is 3, and the description does not add param semantics 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 tool's purpose: verifying cryptographic integrity of the audit trail using SHA-256. It distinguishes from the sibling tool 'get_audit_trail' by noting the difference in scope (entire chain vs. individual agent history).

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

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

Explicitly advises use before relying on audit data for compliance or dispute resolution. Also provides an alternative: use 'get_audit_trail' for individual agent audit history.

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