agent-passport-system-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v5.0.0
Disambiguation2/5
With 150 tools, many overlap in function: there are at least a dozen verify_* tools, six check_* permission gates (purpose, usage, combination, aggregate, jurisdiction, retention), and multiple create_* receipt tools. Even with detailed descriptions, an agent will struggle to distinguish between tools like check_purpose_permitted and check_usage_permitted, or verify_governance_block and verify_aps_txt.
Naming Consistency2/5
Most tools follow a snake_case verb_noun pattern (list_, get_, create_, verify_, check_), but the mutualAuth* tools use camelCase (mutualAuthVerifyTrustBundle, mutualAuthBuildCertificate), breaking the convention. The aps_ prefix is used consistently for a large subsystem, but mixing styles across subsystems makes the overall naming unpredictable.
Tool Count1/5
150 tools is an extreme number for any MCP server, and particularly for one named 'agent-passport-system' which implies a focused identity/passport scope. The server crams in unrelated subsystems like settlement, capability tokens, and mutual auth, which could easily be separate servers. This overwhelms agents and indicates poor scoping.
Completeness4/5
The tool set is highly comprehensive for the domains it covers: passport lifecycle, delegation, task coordination, data governance, attribution, settlement, and mutual auth all have deep and detailed coverage. Minor gaps exist (no explicit passport revocation besides key rotation, no update for tasks, some deprecated tools pointing to a gateway) but agents can work around them.
Average 3.6/5 across 150 of 150 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 48 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says 'apply downgrade', which restates the tool's name and implies a mutating action, but does not disclose side effects, reversibility, permission requirements, or what changes occur to the reputation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, which is efficient. However, its brevity borders on under-specification, sacrificing useful detail for compactness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, no output schema, and no annotations, the description provides an inadequate foundation for invoking the tool correctly. It lacks parameter semantics, return-value expectations, side effects, and any behavioral context beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only accept_from has a description). The description does not explain any of the seven parameters, such as attested_tier, attested_diversity_score, downgrade_ratio, or foreign_default_tier, nor how they relate to the downgrade logic. It fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') and names the resource ('import policy downgrade' to 'foreign vouched reputation'), which makes the purpose clear and distinguishes it from generic tools like update_reputation. However, the phrasing is jargon-heavy and does not explicitly enumerate differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as update_reputation or vouch_reputation. The phrase 'foreign vouched' implies an import-policy context, but there are no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the check purpose, but does not mention side effects (if any), return format, what 'violate' means, or whether it is read-only. Minimal behavioral context beyond the obvious read-only implication of a 'check' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly names the operation and subject. It is concise and well-structured, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, a one-line description is severely incomplete. It lacks essential context about parameter relationships, return values, error conditions, and the meaning of 'aggregate rate limits' in terms of the inputs. The description is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter-level context. The 9 parameters, including required fields like currentAccessCount and windowStartMs, are completely unexplained. The description adds no value over the bare schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'check' with a clear resource 'aggregate rate limits', making it distinct from many other check_* siblings. It states exactly what the tool evaluates, though it does not explicitly differentiate itself from related check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 check_usage_permitted or check_purpose_permitted. The description only states what it does, with no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Register' and provides no details about side effects, persistence, prerequisites, or the meaning of the three-way reporting flow, leaving agents uninformed about important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loaded with the main verb, but the second clause 'Part of three-way reporting' is vague and adds little actionable value. It is concise in length, but not well-structured for conveying useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 7 required, no output schema, and no annotations, this description is drastically insufficient. The agent has no way to understand the three-way reporting context, the semantics of trust_epoch, valid_until, or how the outcome_class and semantic_uncertainty fields relate to each other.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the 8 parameters. Required fields such as semantic_uncertainty, outcome_class, and divergence_score are completely unexplained, and the enums' semantics are left entirely to the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Register' and names the resource 'action outcome', with the useful qualifier 'agent perspective'. However, the 'three-way reporting' phrase is unexplained and does not effectively distinguish this tool from the many sibling tools that also register or create receipts and records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_derivation_receipt, complete_action, or create_access_receipt. The 'Part of three-way reporting' phrase implies some context, but there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely says 'Add a founding signature' without explaining side effects, required permissions, whether the charter must already exist, or any state changes. It doesn't mention the private keys or the signing process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no filler. It is appropriately sized and front-loaded, delivering the core action without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex operation involving 5 parameters (4 required), no output schema, and no annotations. The one-sentence description is grossly insufficient to understand the tool's full behavior, return values, or expected usage, especially given the sensitive nature of private keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only resigner_private_key has a description). The tool description adds no meaning to parameters like charter_id, signer_role, signer_private_key, or signer_public_key, and does not explain their roles or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a founding signature') and the resource ('charter'), using a specific verb and object. It distinguishes from sibling tools like 'add_approval_signature' by specifying 'founding', though it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'add_approval_signature' or 'create_charter'. It lacks any mention of prerequisites, context, or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects, but it merely says 'add a signature.' It does not state that this modifies the approval request, whether the operation is idempotent, or the security implications of supplying a private key. This lack of behavioral disclosure is a significant gap for a mutation tool handling sensitive key material.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording, and it front-loads the main action. However, given the tool's complexity (five parameters, sensitive keys), the brevity borders on under-specification. It is concise and well-structured but sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no output schema, and no annotations, yet the description provides only a minimal functional statement. It lacks any information about the approval workflow, return values, error conditions, or prerequisites. The description is completely inadequate for this context, especially given the sensitive nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the five parameters, but it does not. It fails to clarify key_class, office_id, or the role of the signer_private_key and signer_public_key beyond their names. Users are left with only parameter names and no contextual meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('signature' to an 'approval request'), with a specific verb and object. It distinguishes itself from sibling tools like create_approval_request and sign_charter by specifying the unique operation. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_approval_request, gateway_approve, or sign_charter. It lacks any mention of prerequisites, workflow position, or situations where another tool should be preferred. Users must infer usage context solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 adds only that the attestation is 'signed' and 'proving actual funds,' but omits critical traits such as side effects, idempotency, security requirements (e.g., handling of private keys), or whether it verifies funds before attesting. The description is too sparse to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 12 words, making it very concise. It front-loads the action and purpose. However, the parenthetical '(GPT #15)' is noise that does not aid an AI agent and could be removed, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex: 11 parameters, 3 enums, no output schema, and no annotations. The description provides only a high-level purpose and none of the operational context needed to invoke it correctly. It lacks return value information, error conditions, and any guidance on how parameters interact. This is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate. It mentions 'delegation' and 'funds' but does not explain any of the 11 parameters, such as assurance_class, attestation_basis, or the key fields. The enums are left entirely unexplained, leaving the agent to guess semantics. Some domain context is provided, but it is far from sufficient for correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and object: 'Create a signed reserve attestation' with the purpose 'proving a delegation has actual funds.' This distinguishes it from many sibling attestation tools, though it does not explicitly name alternatives. The parenthetical '(GPT #15)' is a minor distraction but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_derivation_receipt or aps_create_attribution_receipt. There is no mention of prerequisites, common use cases, or exclusions. The tool appears to be an attestation-creation operation, but the description does not help the agent decide when this specific tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 fails to mention any consequences of submission (e.g., finality, triggering review, task closure), prerequisites, or side effects. It merely restates the purpose, offering zero transparency into the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, earning points for brevity. However, it is under-specified: while it is short, it omits critical details that a longer description should include. Thus, it is concise but not effectively structured to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six required parameters, no output schema, and no annotations, so the description must provide substantial context. It offers only a basic statement of purpose, leaving unclear what happens after submission, what makes a submission valid, or how evidence ties in operationally. This is inadequate for a consequential submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all six parameters, so the baseline is 3. The phrase 'tied to evidence' gives slight extra context by suggesting that evidence_packet_ids are central, but it does not meaningfully elaborate on the parameters or their relationships beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Submit') and a specific object ('your final output tied to evidence'), which conveys the tool's purpose. However, it does not explicitly differentiate from sibling tools like submit_evidence or complete_task, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a role hint ('[ANALYST/BUILDER]') but no guidance on when to use this tool versus alternatives (e.g., when to submit evidence vs. a deliverable, or when a task is complete). There are no exclusions or alternative references, so usage guidance is largely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing side effects and operational traits. It mentions signing and echoing but does not explain whether a receipt is stored, returned, or what permissions are required. The private key usage is implied but not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three sentences plus search keywords—and front-loads the 'capability-token gateway receipt' label. It is efficient, though the M2/M3 jargon could be clarified without much extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, lack of output schema, and absent annotations, the description is incomplete. It does not explain the overall flow, return value, or how the inputs like request and gateway_private_key are used, assuming substantial domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, leaving most parameters (request, deny_reason, gateway_private_key, gateway_public_key) undocumented. The description introduces terms like challenge_hash and delegation_chain_root that are not directly mapped to schema properties, adding some context but failing to explain the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool signs a permit or deny over the sink's challenge_hash and echoes the delegation_chain_root, making the core function clear. It distinguishes from siblings like aps_capability_evaluate_authority by positioning itself as the 'M3 gateway receipt' step, though it relies on domain-specific shorthand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as aps_capability_issue_challenge or aps_capability_sign_effect. The description implies it fits an M2-to-M3 flow but does not state prerequisites, sequence, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden of behavioral disclosure. It only states the tool checks permission; it does not disclose the return type (e.g., boolean, reason list), whether it is read-only, or how the constraint types interact with the input parameters. This is insufficient for an agent to predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence with no wasted words, containing the core purpose and example constraints. It is appropriately concise for a simple tool, though it sacrifices necessary elaboration for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the tool returns and how constraints map to the parameters. It does neither, so an agent would not know what to expect from the call or how to interpret the result. The tool is simple, but the description leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (sourceJurisdiction and targetJurisdiction have descriptions; purpose, transferConstraints, and processingRestrictions are undocumented). The description adds no detail about these undocumented parameters and only references constraint names, which are not explicitly mapped to any parameter. It does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool checks whether a data transfer is permitted under jurisdiction constraints, using a clear verb ('Check') and specific resource ('data transfer'). It also lists three constraint types (EU_ONLY, GDPR_ADEQUATE_ONLY, NO_CROSS_BORDER), which helps distinguish it from generic check tools, though it does not explicitly differentiate from the many sibling 'check_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description implies it is for jurisdiction-related transfer checks, but with siblings like check_purpose_permitted, check_combination_permitted, and check_usage_permitted, the absence of explicit usage context or exclusions leaves the agent without a clear selection basis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: the tool approves without executing, which is a meaningful distinction from execution tools. However, it doesn't explain what 'approving' entails (e.g., side effects, reversibility, permission requirements) or what happens after approval. The two-phase execution hint is useful but underdeveloped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys two key pieces of information: deprecation and the two-phase behavior. It is concise and front-loaded with the deprecation notice, which is the most actionable information. However, it's under-specified for a tool with five parameters, so it's efficient but not sufficiently detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema, no annotations) and the availability of sibling tools like gateway_process_tool_call and create_approval_request, the description is notably incomplete. The deprecation notice effectively redirects users away, which mitigates the need for full docs, but for a tool that is still present, it leaves too many details unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. Parameters like agentId, tool, scopeRequired, params, and context are left entirely to their names. The description doesn't clarify the relationship between 'approve' and these parameters (e.g., what 'scopeRequired' means or how 'params' relates to the tool call). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'approve a tool call without executing it.' This specifies the verb (approve) and the resource (tool call). The mention of 'two-phase execution' hints at a distinct workflow that separates it from execution-only tools. However, it doesn't explicitly contrast with sibling tools beyond the deprecation notice, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The deprecation notice explicitly says 'use gateway.aeoess.com REST API' instead, providing a strong 'when not to use' directive. However, it provides no guidance on when one might still use this tool, nor does it compare to sibling tools like gateway_process_tool_call or create_approval_request. The guidance is essentially 'don't use this,' which is clear but incomplete for understanding the tool's intended role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only mentions a prerequisite ('handed off to you') but does not state whether the operation is read-only, has side effects, requires specific permissions, or what the caller should expect in return. This is minimal insight for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately conveys the action and scope. The leading role indicator '[ANALYST/BUILDER/REVIEWER]' is somewhat cryptic and does not clearly earn its place, but it does not significantly detract from the overall conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values, side effects, or how this fits into the workflow. It only says 'Get evidence' without clarifying what the caller receives or whether this consumes evidence. This is insufficient for an evidence-handling tool within a complex governance context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for task_id is simply 'Task ID', which is not informative. The tool description does not explain the role of task_id or how it relates to the evidence handoff, so it adds no meaning beyond the already minimal schema. Although schema coverage is 100%, the schema itself is too weak to serve as a solid baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('evidence') with a qualifier ('handed off to you'), making it clear what the tool does. It distinguishes from sibling tools like review_evidence and handoff_evidence, though it doesn't fully elaborate on how it differs from other evidence retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The qualifier 'that was handed off to you' implies a prerequisite but does not compare with siblings such as review_evidence, list_tasks, or is_evidence_fresh, leaving the agent without enough context to choose among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions hashing content and recording risk class and authoring agent, but does not explain side effects, persistence, reversibility, permissions, or any other behavioral traits. The schema's note that content is not stored is not reflected in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence that states the tool's purpose without extraneous words. It is appropriately sized for the high-level information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, 6 required, no output schema, and no annotations. The one-sentence description is far too thin to give an agent adequate context for required fields, expected behavior, or return values. It is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (2 of 8 parameters have descriptions). The description mentions content hash, risk class, and authoring agent, but the latter is not a schema parameter, and the remaining required fields (delegation_ref, intended_use, artifact_type, valid_until) are left unexplained. The description adds minimal value beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tags an agent-generated artifact with provenance metadata, using the specific verb 'Tag' and a clear resource. It lists metadata types (content hash, risk class, authoring agent), but does not explicitly contrast with sibling tools like create_derivation_receipt or aps_create_attribution_receipt, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent receives no context for selecting it among the many provenance-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action (create) and the general purpose (trace contributing data sources), but does not disclose side effects, data persistence, required permissions, or return behavior. For a mutation tool, this is a significant gap—an agent cannot infer what happens after creating the receipt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the primary action and resource. Both clauses—'Create a Decision Lineage Receipt' and 'traces which data sources influenced a decision'—are informative and earn their place. There is no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is far too thin. It does not explain how to populate the nested contributingSources object, the meaning of lineageCompleteness, or the relationship to access receipts and other governance primitives. An agent would struggle to invoke this correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only decisionType has a description), and the description does not compensate. The phrase 'traces which data sources influenced a decision' loosely relates to contributingSources, but no parameter is explained, and complex fields like lineageCompleteness, transformChain, or governingPurpose remain undefined. The description adds minimal value beyond the raw schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Decision Lineage Receipt and explains it traces which data sources influenced a decision. The specific verb+resource ('Create a Decision Lineage Receipt') distinguishes it from other create_*_receipt siblings, though it doesn't explicitly differentiate from close alternatives like create_derivation_receipt or create_access_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives. The phrase 'Right-to-explanation primitive' hints at its foundational role but does not describe use cases, prerequisites, or exclusions. No sibling tool are named as alternatives, and there is no mention of context in which this should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only says 'Query', which implies a read operation, but lacks details on side effects, authentication requirements, or deprecation consequences (e.g., whether it still works or returns errors). The deprecation notice is the only behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is concise, but it is under-informative. The deprecation notice is front-loaded and clear, yet the lack of any functional or parameter detail makes it feel truncated rather than intentionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 undocumented parameters, no output schema, and no annotations, the description fails to provide essential context about how to use the tool effectively. It only gives a bare hint of its function, making it inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (agentId, purpose, principalId, minAccessCount, sourceReceiptId). The description does not compensate for the lack of parameter documentation, leaving the agent without clues on how to construct a valid query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Query') and the resource ('data contribution ledger'), which distinguishes it from other query tools like list_profiles or resolve_lineage. The deprecation notice is separate but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is deprecated and directs the user to an alternative (gateway.aeoess.com REST API). This provides clear when-not-to-use guidance, though it does not elaborate on when the tool might still be used or explicitly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 doesn't state whether the operation is read-only or mutating, what 'resolve' returns, or whether any side effects or permissions are involved. For a governance-related tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It is front-loaded and contains no filler or repetition, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling governance tools, the lack of annotations, and the absence of an output schema, this description is incomplete. It doesn't explain the return value, edge cases, or the meaning of 'propagate' in this context, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The schema provides a description for sourceDefaultPropagation but not transformClass, and the tool description doesn't mention either parameter or how they relate to the transformation. With 50% schema coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resolve' and identifies the resource as 'rights propagation when data is transformed', making the core purpose clear. It doesn't explicitly differentiate from siblings like resolve_lineage or compute_governance_taint, but the focus on rights propagation during transformation is distinctive enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no scenarios or exclusions. The description simply states what it does, leaving the agent to infer the appropriate context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'check', implying a read-only operation, but does not state the return value, edge cases (e.g., maxRetentionMs null), or whether accessType affects the result. This is a minimal restatement of the tool name with 'TTL policy' added, offering no real behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Check') and the object ('data retention'), with the TTL policy context appended. It is efficient with no filler, though it could briefly note what the function returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is incomplete. It fails to describe the return type or semantics, and does not account for accessType's role or null retention limits. The agent is left without sufficient context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level detail. Schema coverage is 67% (accessedAt and maxRetentionMs have descriptions, accessType only has an enum). The description does not explain accessType's semantic role or how maxRetentionMs null is handled, leaving the uncovered parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('data retention'), and further clarifies the mechanism ('based on TTL policy'). This clearly distinguishes it from sibling check_* tools like check_purpose_permitted or check_usage_permitted, making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for retention-expiry checks, but it does not mention any exclusions or conditions where another tool would be more appropriate, nor does it reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'determine ordering' but does not specify the return format (e.g., boolean, integer, enum), side effects, or error behavior. This is a significant gap for a read-only comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested object parameters and no output schema or annotations, yet the description explains neither the comparison algorithm nor the return value. This is severely under-specified for an agent to invoke and correctly interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only labels the parameters as 'two hybrid timestamps'. It does not explain the meaning of the nested fields (logicalTime, wallClockEarliest, wallClockLatest, gatewayId) or how they influence the comparison.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (compare) and the resource (two hybrid timestamps) and the purpose (determine ordering). It distinguishes from sibling tools such as create_hybrid_timestamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. There is no context, prerequisites, or exclusions, leaving the agent without guidance on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behavioral traits: immutability, freezing at access time, and anti-rug-pull permanence. However, it omits important details like whether it overwrites, required permissions, or what happens to existing snapshots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and front-loaded. 'Anti-rug-pull' is informal but adds semantic value regarding permanence. Minor fluff, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with 7 parameters, no output schema, and complex governance semantics. It does not explain return values, prerequisites, edge cases, or how this relates to the many sibling create_* tools. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 7 parameters. The description loosely alludes to 'terms, jurisdiction, and constraints', which maps to termsVersion, sourceJurisdiction, and allowedPurposes, but provides no explicit meaning for accessReceiptId, sourceId, compensationRate, or currency. This is minimal compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('immutable access snapshot'), and elaborates on what it does: freezes terms, jurisdiction, and constraints. It is distinct enough from most siblings, though ambiguity remains with similar create_* tools like create_access_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description implies a use case (recording access terms) but does not state prerequisites, exclusions, or compare with related tools such as create_access_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('create a request') and mentions 'multi-party,' but does not disclose side effects, permission requirements, whether the request persists, how approvals are collected, or what the response contains. This is minimal for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose efficiently. The use of 'etc.' is slightly vague but does not add unnecessary bulk; the structure is clear and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation tool with 5 parameters (4 required), no output schema, and no annotations, yet the description provides only a high-level purpose. It does not explain expected return values, required fields beyond examples, failure modes, or the multi-party approval workflow. The description is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'subject' has a description), so the description must compensate. It adds some context by mapping subject_type examples ('charter amendments, office transfers') but fails to explain policy_id, requested_by, or timeout_seconds semantics. The agent is left guessing what these fields mean and how they relate to the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('multi-party approval request'), clearly distinguishing it from sibling tools like add_approval_signature or request_human_approval. It also provides concrete examples ('charter amendments, office transfers, etc.') that reinforce what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of subject types but provides no guidance on when to use this tool versus alternatives such as add_approval_signature or request_human_approval. There is no mention of prerequisites, exclusions, or context that would help an agent choose between approval-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states the action without elaborating side effects, required permissions, reversibility, or what occurs upon creation. As a mutation operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant phrases. It is maximally concise and front-loads the core purpose, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no output schema and no annotations. It omits conceptual context about the delegation model, return values, prerequisites, and relationships to sibling tools like create_v2_delegation. The schema covers parameters but not the broader usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented in the schema. The description adds no parameter-specific information beyond the word 'scoped', which aligns with the scope parameter but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a scoped delegation from one agent to another' with a specific verb and resource. It distinguishes from many siblings like verify_delegation and revoke_delegation, but not from create_v2_delegation, which could be confused since it does not address the v1/v2 distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives such as create_v2_delegation or sub_delegate, nor does it specify scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'mandatory sunset' but does not state side effects, permissions, irreversibility, or response format for this creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences and front-loads the core action. While sparse, it avoids unnecessary text and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with four parameters and no output schema, the description is too minimal. It does not explain parameter relationships, prerequisites, or what happens after creation, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description only adds minimal meaning by tying 'mandatory sunset' to the required valid_until parameter. The other parameters (trust_epoch, policy_version, values_floor_version) are left with defaults but no semantic explanation either in the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'v2 PolicyContext' with a mandatory sunset, giving a specific verb and resource. The reference to 'Every v2 object requires one' adds scoping context, though it does not explicitly distinguish from many sibling creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Every v2 object requires one' implies that this tool should be used to satisfy a prerequisite for v2 objects, but it does not explicitly state when to use this tool versus alternatives. There are no clear when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden for behavioral disclosure. It only describes the action ('Declare') without indicating side effects, whether it overwrites existing declarations, required permissions, or reversibility. The scope qualifier adds some context but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence without redundant language. It is front-loaded with the key verb and object, making it easy to scan. However, more details could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the governance/risk context, multiple parameters, and total absence of annotations or output schema, this one-sentence description is insufficient. It does not explain the risk scale, the meaning of 'declared' risk, or what happens after declaration, making it inadequate for an agent to fully understand the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has four parameters with 0% description coverage, and the description fails to explain any of them. Although parameter names like 'risk' and 'assessedBy' are somewhat self-explanatory, the description does not compensate for the low coverage, leaving ambiguous choices such as 'mitigated' vs 'low' or the format of 'mitigationsApplied'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Declare' and a distinct resource 're-identification risk' scoped to 'transformed or synthetic data'. This unambiguously differentiates it from sibling tools like create_derivation_receipt or check_aggregate_constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, conditions, or complementary tools, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It mentions the tool 'returns real pass/fail verdict,' but does not disclose potential side effects, authorization requirements, rate limits, or whether the operation is read-only. The lack of safety or mutation context leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and front-loaded with the core action. The phrase 'real pass/fail verdict' adds a behavioral nuance. The '[OPERATOR]' prefix is odd but not detrimental. Overall, it is tightly written and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the verdict looks like and how to interpret it, but it does not. It also fails to explain the 'Values Floor policy engine' or how the four parameters influence the evaluation. The tool has moderate complexity, and the description leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the description need not restate them. The description adds no extra meaning about how parameters like delegation_scope or delegation_spend_limit affect evaluation, but the schema already provides adequate documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates an intent against the Values Floor policy engine and returns a pass/fail verdict. It uses a specific verb and resource, and the 'intent' focus distinguishes it from many sibling tools. However, it does not explicitly differentiate from related tools like evaluate_revocation_impact or evaluate_threshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions. The context with many governance/policy siblings makes this gap more significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'cryptographically signed' and 'includes terms, revocation policy, and content hash', but does not disclose what happens with the private key, the output format, potential side effects, or failure modes. This is insufficient for a tool that handles cryptographic keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded with the core action. No wasted words, though the second sentence is slightly vague. It communicates essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is far too brief. It does not explain return values, how the governance block is structured, how the policy parameters relate to each other, or any prerequisites. The agent would lack context to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, leaving the 7 enum/other parameters (caching, training, inference, derivative, redistribution, license_url, terms_version) unexplained in both schema and description. The description's mention of 'terms, revocation policy, and content hash' adds high-level context but does not map to specific parameters or clarify their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') with a clear resource ('cryptographically signed governance block') and a distinct purpose ('for embedding in HTML pages'). It differentiates from siblings like 'create_chained_governance_block' and 'verify_governance_block' by emphasizing HTML embedding and cryptographic signing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. It does not mention conditions, exclusions, or related tools like 'create_chained_governance_block' or 'parse_governance_block_html'. The context is only implied by the purpose, not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. However, it only states the action without revealing what happens after the request is made, whether it blocks, how approval is communicated, or any side effects. The lack of behavioral detail is a significant gap for a tool that triggers a human-in-the-loop process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and directly to the point. It contains no extraneous information and is appropriately sized for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain what the caller can expect, such as the approval request ID or status. It also lacks context about the approval workflow, expiry behavior, or how to check the outcome. The description is too sparse to fully guide an agent in using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a description. The tool description itself does not add any additional meaning beyond what the schema already provides, which aligns with the baseline of 3. It does not clarify the semantics of 'expires_minutes' or 'currency' beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to request human approval specifically for a high-value purchase. It uses a specific verb ('request') and identifies the resource ('human approval') along with the context ('high-value purchase'), making the purpose distinct from most sibling tools, though it does not explicitly contrast with similar tools like create_approval_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as create_approval_request or commerce_preflight. There is no mention of prerequisites, thresholds for 'high-value', or circumstances that would make this tool appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It implies a state-changing review process (approve/rework/reject) but does not state whether the action is final, reversible, or requires specific permissions. It also does not mention return values or side effects, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the main action in a single short sentence and listing the verdict options in a fragment. Every word earns its place with no redundancy or filler. It could be slightly more structured, but it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and no annotations, yet the description only covers the main action and verdict options. It does not explain the review workflow, what happens after a verdict (e.g., status updates, rework process), how threshold is used, or what the return value looks like. This is a significant gap for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 7 parameters, including score, verdict, task_id, packet_id, rationale, issues, and threshold. The description adds no additional parameter guidance beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Review an evidence packet. Score it and approve, rework, or reject.' It specifies the verb (review, score) and the resource (evidence packet), as well as the possible decision outcomes. However, it does not explicitly differentiate itself from sibling tools like classify_evidence_quality or evaluate_threshold, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any prerequisites. It does not mention related tools or scenarios, such as whether to use this after submission or before handoff. The usage is only implied by the action description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions a 'signed packet' but does not explain what signing entails, whether submission is final/immutable, what permissions are needed, or what the result/response will be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to stating the tool's action and key qualifier ('signed packet', 'with citations').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, a nested claims array, and no output schema, the description is too sparse. It lacks context about the submission lifecycle, prerequisites, relationship to evidence review/handoff, or what happens after submission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no parameter-specific meaning beyond what the schema already provides; the 'citations' reference is already represented in the claims schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Submit' and the resource 'research evidence as a signed packet with citations,' which is specific and understandable. It does not explicitly distinguish from sibling tools like review_evidence or handoff_evidence, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 this tool versus alternatives such as review_evidence, handoff_evidence, or get_evidence. There are no explicit usage contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'execute an action' with no mention of side effects, required permissions, rate limits, or what the enforcement context implies. This is a significant gap for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the deprecation warning, which is important context. Every word earns its place, though the actual description is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values, error conditions, or side effects, but it does none of that. It is barely more than a label and is inadequate for a tool with 4 parameters and 3 required fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds no additional meaning to the parameters; it does not explain how action_type, target, scope, or estimated_spend relate to the enforcement context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it executes an action through the enforcement context, but 'action' is vague and it does not differentiate from siblings like complete_action or gateway_process_tool_call. It is not a tautology, but the resource and scope are underspecified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly declares deprecation and points to an alternative (gateway.aeoess.com REST API), providing a clear when-not-to-use instruction. However, it does not discuss when the tool was previously used or how it compares to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal important prerequisites (justification for narrowing, reviewer for expansion) but omits critical side effects such as whether the original delegation is invalidated, whether the operation is atomic, or what permissions are required. This is a significant gap for a mutation-like governance tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action is front-loaded, and the two requirement statements are clear and purposeful. This is an example of concise, effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters, no output schema, and no annotations, yet the description only mentions the action and two conditions. It does not explain the return value, the effect on the original delegation, the trust_epoch parameter, or how valid_until should be formatted. This is inadequate for an agent to invoke the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is very low (14%), so the description must compensate. It adds meaning for 'justification' and 'expansion_reviewer' by linking them to scope narrowing and expansion, but it does not clarify the semantics of original_delegation_id, new_scope_categories, valid_until, trust_epoch, or expansion_reviewer_private_key. With seven parameters, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Supersede') and the resource ('a v2 delegation'), which distinguishes it from related tools like revoke_delegation or create_v2_delegation. However, it does not define what superseding entails operationally, so it falls slightly short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete conditions for use: scope narrowing requires justification and scope expansion requires an independent reviewer. It does not explicitly contrast with alternatives or state when this tool should be preferred over revoke or create, leaving the usage context incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially carries the transparency burden by detailing validation steps (receipt must be signed, unexpired, with matching content/principal, and replay protection). However, it does not disclose side effects, return values, or failure behaviors, leaving gaps for a check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, efficiently packed with conditions. However, the opening 'Representation boundary' is cryptic and not self-explanatory, reducing overall clarity despite conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not explain what the tool returns (e.g., boolean, list of failures), how `binding_context` affects behavior, or which fields are required on `artifact`. This makes it incomplete for an agent to safely invoke without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning about how artifact and receipts relate (matching logic, replay protection) but does not clarify the 'binding_context' parameter or provide type details beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'gate a binding artifact's citations' with specific validation criteria (signed, unexpired receipt, content + principal match, replay protection). This distinguishes it from other aps_* tools that focus on different primitives, though 'Representation boundary' jargon slightly obscures clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like aps_verify_attribution_primitive or aps_check_attribution. The description implies a verification/gating role but does not state 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the provenance-preservation aspect but omits side effects like signing, validation of parent block, or failure modes. The short phrase 'Preserves the chain of provenance' adds some context but is insufficient for a creation tool with key inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core purpose and a key property are stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description leaves major gaps: no return value description, no explanation of how parentBlock is used, no mention of key requirements, and no error handling context. It is insufficient for an agent to confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 71% of parameters, but the description does not elaborate on key format, derivation type values, or the meaning of training/inference enums. The only indirect hint is 'references the original publisher's block' relating to parentBlock, but no specific parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the action (create) and resource (chained governance block for derivative content). The phrase 'references the original publisher's block' distinguishes it from generic block creation tools like generate_governance_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like generate_governance_block or create_derivation_receipt. Missing context about prerequisites (e.g., must have parent block, valid keys) or when chaining is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the goal ('so their messages can be verified') but does not disclose side effects, required permissions, idempotency, overwrite behavior, or validation rules. This is a significant transparency gap for a registration tool that likely creates or mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It front-loads the verb and resource, and every word contributes to the meaning. This is an example of efficient brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple registration tool with fully documented parameters, the description is minimally viable. However, with no output schema, no annotations, and no mention of prerequisites or return values, it lacks some contextual completeness. The tool seems simple enough that a 3 is appropriate, but it could easily be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter described ('Agent ID', 'Display name', 'Ed25519 public key'), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register an agent in the Agora') and the purpose ('so their messages can be verified'). It uses a specific verb and resource, making the tool's function understandable. However, it does not differentiate from the sibling tool 'register_agora_public', which may be very similar, so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 this tool versus alternatives. It doesn't mention any context, prerequisites, exclusions, or preferred scenarios. A single declarative sentence with no conditional or comparative information leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It only says it registers a data source and returns a signed SourceReceipt, but does not state whether the registration is persistent, requires authorization, is irreversible, or what the receipt entails. This leaves significant behavioral ambiguity for a governance-related mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two crisp sentences, front-loaded with the verb and resource, and contains no filler. Every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 4 required, no output schema, no annotations), the one-sentence description is inadequate. It omits usage context, preconditions, the meaning of the signed receipt, and relationship to the many sibling tools. This oversight could lead an agent to invoke the tool in the wrong scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 60%, so some parameters have descriptions, but the description itself adds no parameter-level detail. It only generically refers to 'terms for agent access' without mapping to specific fields like allowedPurposes, derivativePolicy, or compensationType, and thus fails to help an agent understand the required inputs beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Register') and resource ('data source'), and adds scope with 'terms for agent access'. It also mentions the return value ('signed SourceReceipt'), distinguishing it from sibling tools focused on receipts, governance blocks, or access checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not reference any sibling tools, mention preconditions (e.g., data hashing or term negotiation), or explain under what circumstances registration is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to state whether the attestation is irrevocable, whether it records a formal commitment, or if any authentication is required, leaving the agent underinformed about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. It conveys the core purpose without unnecessary words, though it could benefit from more context without harming clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a commitment-related action, the description is too sparse. It does not explain the significance of attesting to the floor, the role of extensions, or any potential consequences, and there are no annotations or output schema to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters, so the description adds no additional meaning beyond what is already provided. The high schema coverage (100%) sets a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as 'Attest' and the resource as 'Values Floor', distinguishing it from sibling tools like load_values_floor which loads the floor rather than attesting to it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., the Values Floor must be loaded first) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavior. It only states the classification output; it does not mention whether the operation is read-only, how missing booleans affect grading, or what 'infrastructure' checks are performed, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; it succinctly conveys the action, classification labels, and output range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the return grade and category labels, but lacks usage context, parameter semantics, and behavioral caveats. While the tool is moderately complex (nested evidence object, four parameters, no output schema), the description provides only a minimal functional definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain how method, evidence, has_issuer_signature, and has_principal_binding map to the quality categories or grade. Schema coverage is only 50%, so the description should compensate but does not clarify the boolean parameters' roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'classify' and the resource 'attestation evidence quality', enumerates four quality categories, and states the output grade (0-3). This makes the tool's purpose explicit and distinct from sibling tools like review_evidence or get_passport_grade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over alternatives such as review_evidence or get_passport_grade, nor are any exclusions or prerequisites mentioned. The intended use is only implied by the tool's clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the receipt is signed and supports multi-hop lineage and break markers, adding context beyond the bare name. However, with no annotations, it does not explain side effects, permissions, signing mechanics, or error behavior expected of a create tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations place the burden on the description to explain return values, side effects, and use context. With 9 parameters and related sibling tools, this minimal description leaves significant gaps in what the receipt contains, what 'signed' means operationally, and how it differs from similar lineage tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description indirectly enriches parameters by explaining the domain ('multi-hop lineage' clarifies parentArtifacts chaining; 'break markers' maps to breakReason/externalBoundaryBreak), and schema coverage is moderate at 56%. But it does not explicitly detail any parameter semantics or required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' and identifies resource 'signed derivation receipt' with scope 'tracking how data was transformed' and 'Multi-hop lineage with break markers.' This makes the primary function clear, though it does not explicitly distinguish from similar siblings like create_decision_lineage_receipt or create_artifact_provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_decision_lineage_receipt, create_chained_governance_block, or other receipt/provenance tools. No prerequisites, exclusions, or alternative recommendations are provided; only an implied use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the delegator-only restriction, which is useful, but omits side effects, prerequisites, consequences of defining an emergency pathway, or any interaction with other delegation tools. This is a significant gap for a tool that creates something.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word adds value. It avoids redundancy and fluff, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, no annotations, and no schema-level descriptions. The description only states the purpose and a single authorization constraint, leaving out essential context about trigger semantics, scope expansion, review deadlines, and how this relates to the delegation lifecycle. For such a complex tool, the description is woefully incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter explanations. This is a critical issue for 11 parameters, including trigger_field, trigger_operator, delegation_ref, expanded_scope_categories, and review_authority, all of which are core to the tool's function. The agent has no guidance on how to correctly populate these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Define' and the resource 'pre-authorized emergency pathway', making the tool's function unambiguous. It also distinguishes this tool from siblings like 'activate_emergency' by specifying 'at delegation time' and the delegator-only authorization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool ('at delegation time') and provides a clear exclusion ('Only the delegator can define these'). However, it does not explicitly name alternatives or describe when not to use it beyond the delegator constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the tool is read-only, what it returns, or any side effects. It only states the high-level detection goal, leaving the agent to guess at behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly-worded sentence with an illustrative example, making it front-loaded and free of filler. However, for a tool with four parameters, it is arguably too terse to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal parameter explanation, the description leaves significant gaps for an agent trying to invoke the tool correctly. It does not explain what constitutes 'drift' or how to structure the arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain the meaning of parameters such as allowedPurposes or intermediateSteps. The only hint is the example values 'research' and 'commercial', which are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as detecting purpose drift in workflows, with a concrete example (research → commercial). This distinguishes it from sibling tools like check_purpose_permitted, which presumably verify permissions against a policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 analyzing workflow purpose transitions, but it does not explicitly state when to prefer it over other governance tools, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states 'Get a message thread from the Agora feed.' It does not mention whether the thread includes nested replies, ordering, permissions, or any side effects. The absence of such context is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is well-structured and front-loaded, delivering the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the tool has no output schema or annotations, so the description should clarify what 'thread' means (e.g., flat list, tree, message contents) and any usage constraints. The current description is too sparse to be considered complete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description of message_id ('Root message ID to get thread for'), and schema coverage is 100%. The tool description adds no additional parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a message thread from the Agora feed, using a specific verb ('Get') and resource ('message thread'). This distinguishes it from siblings like get_agora_topics, which deal with topics rather than threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related Agora tools such as get_agora_by_topic or post_agora_message. Sibling names exist but are not referenced, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as return format, pagination/ordering, permissions, or side effects. 'List' implies a read-only action, but the description does not explicitly state safety or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is properly front-loaded with the verb and resource. It contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, no output schema, no annotations), the description is minimally viable but still leaves gaps. It does not explain the return structure or limitations, and there is no mention of how it relates to task details, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema fully covers that fact. With no parameters, the description does not need to add parameter details, so the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('tasks in the coordination store'), clearly distinguishing it from sibling tools like list_profiles or get_task_detail. However, it does not explicitly distinguish from alternatives in the text, relying mostly on the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_task_detail or list_profiles. No exclusions, prerequisites, or alternative suggestions are provided beyond the implied use case of listing all tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the destructive revocation action and cascade capability, but omits important behavioral details such as whether revocation is reversible, what permissions are needed, or what happens to dependent artifacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every element serves a purpose: the action, the resource, and the optional cascade behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operator tool with no output schema and no annotations, the description is too sparse. It lacks context on revocation consequences, usage scenarios, and relationships to other delegation lifecycle tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all three parameters. The tool description adds little beyond the schema, only echoing the cascade behavior already documented in the schema parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revoke a delegation') and adds scope ('Optionally cascade to all sub-delegations'), distinguishing it from sibling creation, verification, and sub-delegation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 supersede_v2_delegation or sub_delegate. No prerequisites, exclusions, or contextual hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the SDK derives and signs the preimage, MCP never sees or builds signed bytes, and amendments are ephemeral (lost on restart, no external trust). This is valuable transparency beyond the bare action, clarifying side effects and the trust model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The primary action is stated upfront, followed by essential process and trust caveats. Every clause adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for a mutation tool: it does not describe the return value (no output schema), error conditions (e.g., amendment not found), or prerequisites beyond the amendment being proposed. The trust model note is helpful but does not fill the gaps needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only signer_role has a description). The description does not explain amendment_id, signer_private_key, or signer_public_key. It contextually implies these relate to signing, but offers no explicit semantics, formats, or relationships. Given the low coverage, the description should compensate but barely does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a signature to a proposed amendment.' It includes a specific verb (add), resource (signature to amendment), and adds process context (SDK derives and signs). While it doesn't explicitly differentiate from sibling tools like add_approval_signature or sign_charter, the target ('proposed amendment') is unambiguous enough for an agent to grasp its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for signing a proposed amendment) but provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives, nor does it explain the prerequisite that an amendment must already be proposed. The caution about session state is useful but not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral detail. It does not disclose side effects, irreversible consequences, required permissions, or what happens upon activation. For a critical emergency operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely conveys the core action. It is appropriately sized, though it could provide more context while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is too sparse. It lacks information about activation semantics, valid_until format, trust_epoch meaning, and potential effects. The description does not fully equip an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only trigger_evidence having a description. The tool description adds 'with evidence' but does not explain pathway_id, trust_epoch, or valid_until. The parameter names give some hints, but the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: activating a pre-authorized emergency pathway. The verb 'activate' and resource 'emergency pathway' are specific, and it distinguishes from sibling 'define_emergency_pathway' which handles creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an emergency pathway is pre-authorized and needs activation, but it does not explicitly state when to use it versus alternatives, nor mention prerequisites like prior definition of the pathway. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosure. It indicates a mutation (adding) without explaining side effects, such as whether it overwrites, requires existing records, or has any idempotency. The 'three-way divergence reporting' hint adds purpose but not behavior, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It is front-loaded with the core action and immediately provides the purpose context, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four required parameters, no output schema, and no annotations, the description is too minimal. It omits usage guidance, parameter details, and behavioral disclosure, leaving the agent with insufficient information to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fails to explain any parameter meanings. While a reader might infer that parameters like outcome_id and observed_outcome relate to the principal's report, the description does not explicitly map them. This leaves the agent to guess from field names and the enum for outcome_class.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: adding a principal's perspective to an existing outcome record. The phrase 'Enables three-way divergence reporting' gives additional context that differentiates this from sibling tools like create_outcome_record, which creates the record itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need to add a principal's perspective to an outcome record—but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites like requiring an existing outcome record. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses that the tool 'creates a delegation automatically,' which is a meaningful side effect. However, it does not mention any required permissions, potential overwrites, reversibility, or what the response looks like. For a mutation tool, this is not enough transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences totaling 15 words. It is front-loaded with the primary action and adds the key side effect without any fluff. Every word contributes to the tool's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is minimal. It covers the core action but fails to mention the return value or clarify the role of sensitive parameters like agent_public_key and spend_limit. It is adequate for a basic understanding but leaves gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add any meaning beyond the schema; it merely restates the overall purpose. The parameters like spend_limit and agent_public_key are not explained further in the description, but the schema already provides adequate descriptions for each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Assign an agent to a role in a task' and adds the key side effect 'Creates a delegation automatically.' This is a specific verb and resource, and it differentiates the tool from generic delegation tools like create_delegation by focusing on role assignment within a task. However, it does not explicitly name sibling alternatives or scope boundaries, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 an agent needs to be assigned a role in a task and a delegation should be created. It does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives such as create_delegation, sub_delegate, or create_v2_delegation. The usage context is inferable but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool prevents prohibited inferences and lists regulations, but it does not disclose return format, side effects, or error behavior. It is unclear whether this is purely read-only or if it blocks operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and includes regulatory context without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and no output schema or annotations, the description is too sparse. It does not explain expected return values, parameter usage, or behavior when a combination is not permitted, leaving the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the six parameters. Parameter names like otherSourceId and forbiddenSourceIds are weakly self-describing, but 'reason' and 'otherSourceClasses' remain ambiguous. The description gives only a vague hint that two sources are involved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether combining data from two sources is permitted, with the regulatory context preventing prohibited inferences. It distinguishes from sibling check tools by specifying the combination scenario and relevant regulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when combining data from two sources, but it does not explicitly state when not to use it or mention alternatives such as check_purpose_permitted or check_aggregate_constraints. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the check action but does not mention return format (e.g., boolean), error handling for invalid block JSON, or whether the operation has side effects. The word 'check' implies read-only, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It delivers the core purpose efficiently, making it easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters and no output schema, so the description should clarify the return value and any prerequisites. It only states the core function, leaving the agent to infer return semantics and error behavior, which is insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for 'block' and an enum for 'usage', but coverage is only 50%. The description adds little beyond restating that a usage type is checked; it does not explain how the block JSON should be structured or what the usage values mean. It fails to compensate for the partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('check') and resource ('usage type permitted under a governance block's terms'). It distinguishes itself from sibling tools like check_purpose_permitted by focusing on usage type rather than purpose, and from other check_ tools by naming governance block terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use this tool (to verify a usage type under a governance block), but it does not provide explicit guidance on alternative tools or exclusions. The description does not compare with siblings like check_combination_permitted or check_purpose_permitted, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It reveals the timestamp composition (HLC + NTP uncertainty) but does not disclose side effects, permissions, persistence, or return behavior. For a creation tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and key distinguishing detail. It contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters and no output schema, the description is mostly adequate for a basic create operation. However, it does not explain what is returned (e.g., timestamp value, ID, confirmation) nor any usage context, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains both parameters. The description adds no additional meaning or format details beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and identifies the resource 'hybrid timestamp' with a qualifier 'gateway-issued' and a technical parenthetical 'HLC + NTP uncertainty'. This clearly distinguishes it from siblings like compare_timestamps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, contexts, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral context. It discloses the deprecation status, which is useful, and hints at an enforcement boundary, but it gives no details on side effects, permissions, or return behavior beyond that. This is a minimal but not worthless disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and avoids waste, but it is under-specified. The deprecation notice is a legitimate sentence, and the purpose statement is concise; however, it lacks necessary elaboration, so it is not a model of efficient completeness. It earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 7-parameter schema with no parameter descriptions, no output schema, and no annotations, the description is far too thin. It provides no guidance on parameter values, behavior, or expected outcome, and only offers a deprecation warning. The tool would be hard to invoke correctly based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to any of the 7 parameters. It does not mention agentId, tool, scopeRequired, or any other field, leaving the agent without any clue as to what these parameters represent or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Process a tool call') and the specific context ('through the gateway enforcement boundary'), which is a specific verb+resource combination. However, it does not distinguish this from sibling gateway tools like create_gateway or gateway_approve, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is deprecated in v3.0.0 and directs users to use the gateway.aeoess.com REST API instead. This is a clear when-not-to-use directive and names an alternative, which fully satisfies the highest guideline criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only says 'Get all messages', which implies a read-only operation, but does not describe return format, ordering, pagination, or any potential side effects. Minimal value added beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly to the point, no wasted words. Properly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema, no annotations) and the description covers the basic purpose. However, it lacks context about how 'topic' is identified, what the return value contains, and how it relates to sibling tools like get_agora_thread. Adequate for a trivial getter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'topic' described as 'Topic to filter by'). The description adds no extra meaning beyond the schema, but the schema is already clear. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all messages in a topic'. It is specific enough to distinguish from sibling tools like get_agora_topics (list topics) and get_agora_thread (likely a thread view), though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_agora_thread or get_agora_topics. The description lacks any context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only states the transfer action without mentioning side effects, permissions, reversibility, or state changes. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. The [OPERATOR] prefix is concise and informative, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five required parameters and no output schema. While the schema covers parameter semantics, the description omits operational details like approval prerequisites, permission requirements, or what happens after transfer, leaving the overall context only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a description. The description adds a contextual hint about the typical flow (researcher to analyst) but does not elaborate on the parameters themselves, which is acceptable given the schema richness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Transfer'), a clear object ('approved evidence'), and the direction ('from researcher to analyst'), making it easy to distinguish from sibling tools like submit_evidence or review_evidence. The [OPERATOR] prefix adds further context for usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as submit_evidence or get_evidence. The description implies the transfer happens after approval but does not state prerequisites, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the tool sets role and scopes tools, but it does not mention security implications of sending a private key, whether the operation is idempotent, what happens to prior identity, or side effects beyond scoping. For an authentication/identity tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action, and no filler. Every word contributes to explaining the tool's core purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema fully documents parameters, there is no output schema and no annotations. The description covers the core purpose but omits prerequisites, return behavior, security warnings, and when this should be used relative to other identity tools, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no parameter-specific meaning beyond what the schema provides, which meets the baseline but does not go further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Identify yourself to the coordination server') and its effect ('Sets your role and scopes tools accordingly'). It distinguishes the tool's purpose from many siblings, though it does not explicitly contrast with related identity tools like get_my_role or issue_passport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: identifying yourself is a prerequisite for the coordination server to set your role and scope tools. However, there is no explicit 'use this when' guidance or mention of alternatives, so the agent must infer when this should be called relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds key facts that posts are signed and publicly readable, which is useful. However, it does not mention any requirements (e.g., authentication, key availability), potential irreversibility, or response details, leaving gaps in the behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and resource, followed by a concise behavioral note. Every word earns its place; there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple post tool with a well-documented schema, the description is reasonably complete. However, with no output schema and no mention of return values, authentication, or error conditions, an agent might be unsure about what to expect after invoking it. The description covers the core intent but not the fuller operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, so the description does not need to explain them. The description adds no extra parameter-level context, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a signed message') and the resource ('the Agora feed'). It distinguishes itself from many siblings by focusing on the Agora feed, but it does not explicitly name alternative tools for comparison, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like send_message or broadcast. It states that 'anyone can read' implying public visibility, but this is more a property than a usage condition, and no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of disclosing behavioral effects. It explains the semantic intent ('I no longer authorize this agent') but does not disclose whether the action is reversible, whether permissions are required, or what consequences occur for existing verifications. Since this is a mutation/revocation tool, that is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and is fully front-loaded with the action and resource. The quote adds efficient semantic color without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple revoke-by-ID operation the description gives the core semantics, but it omits behavioral details like reversibility, side effects, and whether an impact check is recommended before use. Given no annotations and no output schema, the description is acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (endorsement_id, reason) have clear descriptions in the input schema. The description does not add parameter-level meaning beyond the schema, so it meets the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'revoke' and clearly names the resource: 'a principal's endorsement of an agent.' The clarifying quote 'I no longer authorize this agent' reinforces the operation and distinguishes it from sibling tools like endorse_agent and verify_endorsement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives; it does not mention evaluate_revocation_impact or revoke_delegation, nor any prerequisite like checking impact before revoking. The usage context is only implied by the tool name and basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions verification components and the return value but does not state whether it mutates state, the nature of 'end-to-end' verification, failure behaviors, or how the optional 'now' parameter affects the evaluation. 'Representation boundary' adds little clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that includes purpose, scope, and return value. It is concise and front-loaded, though 'Representation boundary' could be removed as mildly cryptic and unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description provides a reasonable overview, but it lacks guidance on when to use this versus related verification tools, detailed semantics of 'end-to-end', and any behavioral caveats. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the description is not required to add parameter details. It mentions receipt fields, but this does not directly enhance the parameter semantics beyond what the schema already says. Meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies an AttributionReceipt 'end-to-end', listing the specific components checked (id, signatures, expiry). It distinguishes this from sibling tools that verify primitives or projections, and also states the return shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: use when you need to verify a full AttributionReceipt. However, there is no explicit guidance on when not to use it or how it differs from related verification tools like aps_verify_attribution_primitive or aps_verify_attribution_projection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a finalizing/mutating operation but does not disclose whether the action is irreversible, whether operator permissions are required, or what happens to the task unit after closure. The '[OPERATOR]' prefix hints at privileged use but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action without any wasted words. The '[OPERATOR]' prefix provides useful context about the tool's intended audience without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a consequential close/finalize operation with no annotations and no output schema, the description is under-specified. It does not explain whether the retrospective is required (schema shows it is not), whether closure can be reversed, what the resulting state is, or any side effects. The schema covers parameters but not the behavioral context needed for an AI agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions already define 'Final status' and 'What went well, what didn't'. The description's mention of 'final status and retrospective' adds no new semantic 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Close' with a clear resource 'task unit' and specifies the action includes final status and retrospective. This clearly distinguishes it from sibling tools like complete_action by focusing on task-level closure rather than general action completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when closing a task unit, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention exclusions or prerequisites. The sibling complete_action could be confused with this, and no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the hash components, timestamp normalization, and equivalence property, which is useful. However, it does not mention side effects, error handling, or explicitly state that it is a pure/deterministic function, though that is largely inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, direct, and front-loaded with the core action. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a hash-computation tool, the description states the core behavior and key property (same action_ref = same request). Without an output schema, it does not explicitly state the return type, but 'SHA-256' implies a string output, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%, only timestamp has a description). The description compensates by mapping agentId, actionType, scope, and normalized timestamp to the hash formula, clarifying how each contributes. Yet it does not elaborate on what scope_required means or other input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a content-addressed request identity (SHA-256 of agentId + actionType + scope + normalized timestamp), providing a specific verb and resource. It explains the output's significance. However, it does not differentiate from similar sibling tools like aps_compute_attribution_action_ref.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The deduplication property ('Two receipts with the same action_ref describe the same request') implies a use case but is not framed as a usage condition or alternative exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, whether it requires specific permissions, how it handles missing derivation chains, or what the output format is. This leaves significant ambiguity for a compute tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly communicates the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with no annotations and no output schema. It does not mention the return value, possible error cases, or any prerequisites (e.g., must have lineage resolved). Given the likely complexity of a governance taint calculation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (revokedSources is described, artifactId is not). The description adds the concept of 'derivation chain' and implies artifactId identifies the artifact, but it does not fully compensate for the missing schema description on artifactId or clarify how the inputs interact beyond a general statement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a governance taint level, using specific input concepts (derivation chain, revoked sources). This distinguishes it from sibling tools like evaluate_revocation_impact, which focuses on broader impact rather than a computed taint score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a taint level is needed, but provides no explicit guidance on when to use it over alternatives or any exclusions. There is no mention of scenarios where another tool would be more appropriate, such as evaluate_revocation_impact or resolve_lineage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool 'creates' a disclosure, implying mutation, but does not mention permissions, reversibility, side effects, or output structure. The phrase 'controls how much info is revealed' adds a bit of context but is insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences that convey the tool's purpose without waste. Every word contributes to meaning, making it highly concise and appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no output schema, no annotations), the description is adequate. The parameter is fully covered by the schema, and the description explains the core concept. However, it could be more complete by mentioning the intended context or expected output, but for a simple create operation with full schema coverage, it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'level' parameter is fully documented with enum values and descriptions). The tool description adds no additional meaning beyond the schema; it merely reinforces that the level controls revelation. Since the schema already carries the parameter semantics, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('selective disclosure of principal identity'), clearly indicating the tool's function. It also adds 'Controls how much info is revealed' to clarify the tool's effect. However, it does not explicitly distinguish this from sibling tools like 'issue_passport' or 'identify', which could serve related purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to create a selective disclosure and control information revelation, but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. This is an implicit usage cue rather than direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'declare' and references a '3-signature chain' without explaining side effects, persistence, authorization requirements, return values, or irreversibility. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main verb, no redundant phrases. The description is appropriately concise and every word contributes meaning, even though it comes at the cost of depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, no annotations, and no output schema, this two-sentence description is under-specified. It does not explain what the '3-signature chain' entails, the role of delegation_id/scope_required, or the tool's place in the overall workflow, leaving significant gaps for a complex initiating step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds no additional parameter semantics beyond the schema; it only loosely maps to action_type and target via 'perform an action'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('declare an intent') and adds process context ('first step of the 3-signature chain'). This distinguishes it from later chain steps or other create_* tools, making the purpose 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'first step' wording implies this tool initiates the intent chain, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent can infer usage from the context, but it is not strongly differentiated from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It states 'Propagates obligations through derivation chains,' which signals a side effect but leaves ambiguity about whether this is a read-only evaluation or an active mutation. It does not clarify data modifications, reversibility, permission requirements, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences. The first names the purpose, and the second adds a key behavioral detail. There is no fluff or redundant phrasing; every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool likely has complex behavior (propagating obligations through derivation chains), yet the description gives no details about output, side effects, or edge cases. There is no output schema to clarify return values, and the absence of annotations forces the description to bear the full burden, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'sourceId' is fully described in the schema as 'Source ID that is revoking consent.' The description's mention of 'data source revokes consent' aligns with this but adds no additional meaning beyond the schema. With 100% schema coverage, the description does not need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: evaluating what happens when a data source revokes consent, and specifically mentions propagation through derivation chains. This is more specific than sibling tools like 'resolve_lineage' or 'resolve_rights_propagation', and the verb 'evaluate' plus resource 'revocation impact' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when a data source revokes consent, this tool evaluates the impact. However, it does not explicitly mention when to use this tool over alternatives, nor does it provide exclusions or prerequisites. Sibling tools with similar governance themes (e.g., 'resolve_lineage', 'resolve_rights_propagation') are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Get' which implies read-only, but it does not disclose side effects, permissions, data scope, or output format. The description adds no behavioral context beyond the plain action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded with the action verb and resource. Every word earns its place with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves the agent without critical context about what 'spend analytics' returns or any behavioral constraints. It is minimal and does not compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add additional meaning beyond mentioning 'commerce delegation,' which only maps to delegation_id and does not clarify the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a unique resource ('spend analytics') with a clear scope ('for a commerce delegation'). This clearly distinguishes it from sibling tools like 'commerce_preflight' or 'get_evidence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving spend analytics but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The use case is obvious, but no concrete direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it merely restates the function. It omits any details about side effects, session state requirements, or what the returned history contains or looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is appropriately minimal for a tool with no parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse to be complete for an agent. It does not explain what a 'promotion review' is, what 'history' includes, or what the response format will be. Since there is no output schema or annotation to clarify, the agent is left with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds no parameter-level meaning. The baseline of 4 for parameterless tools applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('promotion review history'), and scopes it ('for this session'). It clearly distinguishes from the sibling tool 'review_promotion', which implies an action rather than a history lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no indication of prerequisites, conditions, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, permissions, and failure modes. It only mentions a constraint on scope/depth, but not what happens when the constraint is violated, whether it creates a permanent record, or whether it requires existing delegation. This lacks transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and includes a relevant constraint. No wasted words, but it is arguably too terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters and no output schema, and the description is only one clause. It does not explain the delegation workflow, error conditions, or relationship to sibling delegation tools. For a tool that modifies authority, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters at 100% coverage, so the baseline is 3. The description adds no parameter-specific information beyond restating the constraint already present in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sub-delegate authority to another agent') and adds a scoping constraint, distinguishing it from create_delegation and other delegation tools. The verb+resource 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the requirement to be 'within your delegation scope and depth' and the requirement of a parent_delegation_id, but it does not explicitly state when to prefer this over alternatives like create_delegation or create_v2_delegation. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry full behavioral disclosure. It mentions verifying 'cryptographic signature and validity' but does not disclose output format, error behavior, or whether expiration/revocation checks are included. This is a significant gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the action and target, making it appropriately concise for a simple verification tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is under-specified. It does not clarify what 'validity' encompasses (e.g., expiration, revocation) or what the tool returns. Given missing annotations and output schema, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description for delegation_id ('Delegation ID to verify'). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'verify' with the resource 'delegation' and specifies what is verified ('cryptographic signature and validity'). This clearly distinguishes it from sibling verification tools like verify_charter and verify_governance_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking delegation validity but provides no explicit guidance on when to use this tool versus alternatives. Sibling tools like verify_charter, verify_endorsement, and create_delegation suggest potential ambiguity, yet no exclusions or when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'Confirms you're ready to work,' which is minimal. It doesn't disclose whether the action is reversible, what side effects occur (e.g., status change, notification), or any permissions needed. For a state-changing action, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the action, then provides a clarifying consequence. Every word earns its place, and the [ANY ROLE] prefix is a succinct access hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema), so the description is adequate for basic understanding. However, it doesn't explain the broader workflow context, such as what happens after acceptance, whether it triggers other processes, or the expected result. It's functional but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (task_id is fully described), so the baseline is 3. The description adds no extra meaning for the parameter beyond tying it to the assignment, but it doesn't need to since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Accept') and resource ('your task assignment'), and the possessive 'your' clearly distinguishes it from assign_agent (assigning someone else) and complete_task (finishing). The scope is explicit, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you use it when you have a task assignment and want to confirm you're ready to work. However, it provides no explicit when/when-not guidance or alternatives, leaving the agent to infer context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states only that a task is created, but does not disclose whether permissions are needed, whether creation is reversible, what the response/return value is, or any side effects. This is insufficient for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action ('Create'), and every phrase adds information about the task's composition. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (6 parameters, no output schema, no annotations), the description is adequate but leaves gaps: it does not explain expected return values, any constraints or side effects, or operational context. The rich schema compensates partially, but the description is minimal and could be more complete for an agent to invoke with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds marginal value by highlighting roles, deliverables, and acceptance criteria, but does not provide additional meaning beyond the schema's own descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('new task') and explicitly names key components (roles, deliverables, acceptance criteria). This clearly distinguishes it from sibling tools like list_tasks or get_task_detail, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Create' implies this tool is for creating new tasks, and the listing of required fields suggests when to use it. However, there is no explicit statement of when to use this versus alternatives, nor 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.
Behavior2/5
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 delegation has mandatory sunset and PolicyContext binding, but does not explain prerequisites, side effects on existing delegations, or how versioning works. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and information-dense. Every phrase adds value: 'v2', 'versioning', 'mandatory sunset', and 'PolicyContext binding' are all meaningful discriminators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level overview but omits details about the return value, how PolicyContext binding is established (no corresponding parameter), and the implications of versioning. For a create operation with no output schema, more context is needed for full agent confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with trust_epoch undocumented. The description does not add meaning beyond the schema; 'versioning' might hint at trust_epoch's purpose but is not explicit. Since coverage is moderate, the description leaves a gap for trust_epoch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a v2 delegation, distinguishing it from the sibling create_delegation (likely v1). The mention of versioning, mandatory sunset, and PolicyContext binding clarifies the specific resource and variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and feature list imply when to use this tool (for v2 delegations with sunset and policy binding), but the description does not explicitly state when to prefer it over create_delegation or supersede_v2_delegation, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that a cryptographic chain is created, which hints at the operation's nature, but it does not disclose whether the endorsement is additive or replacing, whether it requires special permissions, whether it is reversible, or what the return value is. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two short sentences that convey the core purpose and mechanism. It is front-loaded with the verb and resource, and every word adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 5 parameters and no output schema. The description provides a clear purpose and the schema fully documents parameters, making it minimally viable. However, the absence of annotations, output schema, and usage guidance leaves gaps in understanding side effects, return values, and alternate tool selection, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with meaningful descriptions, so the baseline is 3. The description does not add parameter-level context beyond the schema; it does not explain the relationship enum or provide examples for scope. It offers no additional value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Endorse an agent as a principal' with a specific verb and resource. It adds the detail 'Creates a cryptographic chain: principal → agent,' which clarifies the mechanism and distinguishes it from sibling tools like verify_endorsement and revoke_endorsement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to create an endorsement) but provides no explicit guidance on when to use this tool versus alternatives such as verify_endorsement or revoke_endorsement. It does not mention prerequisites or the intended context for endorsing an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does reveal a key trait: the tool only records disputes and does not resolve them (resolution is external). However, it omits other behavioral details such as permissions, side effects, idempotency, or return behavior, so it is only minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant wording. Each sentence adds meaningful information: the action and the key limitation (external resolution). It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, no annotations, and no output schema, the description is too sparse. It does not provide enough context for an agent to correctly invoke the tool – e.g., who should be filedBy, what dispute types are valid, what evidence is needed, or what the outcome of filing is. The description is a minimal placeholder rather than a complete guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'evidence' has a description), so the description must compensate. It adds the meaning that the dispute is 'against a data artifact,' which clarifies artifactId, but it fails to explain filedBy, disputeType categories, or how to structure evidence. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'File a dispute against a data artifact' – a specific verb and resource. It further distinguishes the tool from resolution-focused siblings by noting 'The protocol records disputes — resolution is external.' This gives a crisp, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'resolution is external' implies this tool is for filing only, not resolving disputes, but it does not explicitly name alternative tools or state when not to use it. The usage context is clear enough for basic selection but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It says 'Compute' and lists return values, but it does not state whether the operation is read-only, whether any permissions are required, how it handles invalid scopes or unknown agents, or whether it has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every element is substantive: the verb, the subject, the scope qualifier, and the list of return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must compensate by explaining return values, and it does list them. However, it omits behavioral context (side effects/errors) and does not mention the required principalId parameter's role in the computation, making it merely adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains all three parameters. The description adds no additional param-level detail beyond the phrase 'agent in a given scope,' which maps to agentId and scope but does not clarify principalId's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and clearly identifies the resource/outputs ('effective reputation score and authority tier', plus autonomy level, spend limit, and effective score). It clearly distinguishes this from sibling tools by emphasizing the computed effective score and scope-specific authority details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: whenever an agent's effective reputation score and authority tier in a given scope are needed. However, it does not explicitly mention alternatives or exclusion conditions, such as when to use check_tier or evaluate_threshold instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the creation of a signed artifact and a eligibility requirement, but does not mention failure modes, side effects, or what 'signed' implies beyond the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word contributes meaning. No wasted words or redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description gives the essential action, a prerequisite, and the return artifact. However, it leaves domain-specific terms like 'earned' unexamined and does not clarify how this tool relates to similar promotion siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 well-documented. The description adds no additional meaning to the parameters, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a signed promotion review for another agent, with a specific verb and resource. It is distinguishable from sibling tools like review_evidence, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key prerequisite (reviewer must have 'earned' origin and tier above target) but does not explicitly say when to use this tool versus alternatives or when not to use it. Context is implied rather than enumerated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 specifies the verification checks but does not disclose output format, read-only nature, error behavior, or potential side effects. For a verification tool, the absence of any statement about result type or failure handling is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource, with no redundant wording. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters, but the description omits the output format and any usage guidance, and there is no output schema to compensate. It is minimally viable for selecting the tool but incomplete for fully predicting invocation results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (content as aps.txt JSON, publicKey as Ed25519 hex key). The description adds the concepts of 'signed' and 'DID consistency,' but it does not materially enhance parameter understanding beyond the existing schema descriptions. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and names the exact resource ('signed aps.txt file'), and it states what the verification entails ('checks signature and DID consistency'). This clearly distinguishes it from sibling tools like generate_aps_txt or other verify_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used to verify a signed aps.txt file, but it does not explicitly state when to use it versus alternatives (e.g., verify_charter, verify_issuer) or provide any exclusion criteria. This is implied rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states this is a request for permit/deny but does not disclose side effects, whether it mutates state, consumes the token, is idempotent, or has security implications. The mention of a 'revealed authority-token preimage' hints at sensitivity but leaves out consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus search keywords. Every sentence adds protocol context. The jargon (v0.1, M2, sink) is dense but purposeful for the domain. The search keywords are a minor extra but do not hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, nested objects, no output schema), the description explains the overall purpose and the flow but omits expected return format (permit/deny response structure) and any prerequisites beyond M1. It is adequate for a protocol-literate developer but not self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the schema already documents most parameters. The description adds context by mapping 'sink's M1' to challenge, 'delegation chain' to delegation_chain, and 'authority-token preimage' to authority_token, but it does not explain the less-covered fields like freshness_beacon or the nested token_preimage/merkle_proof semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a capability-token authority evaluation request (M2) and explains the protocol flow: the subject signs a request carrying M1, delegation chain, and token preimage, which the gateway consumes to permit/deny. This distinguishes it from sibling tools like aps_capability_issue_challenge (M1) and aps_capability_mint_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is the M2 step after receiving the sink's M1, and it is used to request an authority decision. It does not explicitly list when-not-to-use or alternative tools, but the protocol framing and sibling names imply a specific place in the capability-token flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the message is signed, which hints at authentication, but it does not disclose potential side effects, permissions required, delivery guarantees, or return behavior, leaving significant gaps for a mutation-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and scope. It contains no filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema documents all parameters, there is no output schema and no annotations, so the description should explain return values or side effects. It only provides the basic action and target, leaving out important context like success/failure behavior, signing mechanism, or delivery semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters. The description adds no parameter-level detail beyond indicating the message is signed, which does not improve on the schema, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send'), a clear resource ('a signed message'), and an explicit scope ('to all agents'), making the tool's purpose unambiguous. It also names the endpoint ('comms/broadcast.json'), which helps distinguish it from sibling tools like send_message or post_agora_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for broadcasting to all agents, which gives context for when to use it. However, it does not explicitly mention when NOT to use it or point to alternatives for direct or targeted messaging, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the receipt captures terms and revocation policy, but does not disclose side effects, how the private key is used or handled, whether data is persisted, or what the output looks like. Some context is added, but critical behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Create a signed access receipt') followed by a clarifying detail. Every word contributes to understanding the tool's purpose; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 required parameters, no annotations, and no output schema. The description does not explain the return value, prerequisites, or any security considerations around submitting a private key. For a cryptographic operation with a private key input, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-defined in the schema. The description adds minimal extra meaning, only hinting that 'terms and revocation policy' relate to the block parameter. This aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a signed access receipt — cryptographic proof that your agent consumed content under specific terms.' It uses a specific verb and resource, and distinguishes itself from sibling receipt tools by emphasizing 'access' and 'revocation policy at access time.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (proof of content consumption under terms) but does not explicitly state when to use this tool over similar ones like create_derivation_receipt or aps_create_attribution_receipt. 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.
Behavior2/5
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 indicates the tool creates a charter defining offices, amendment rules, and dissolution policy, but it omits critical side effects: permission requirements, irreversibility, the use of founder private keys, or what the caller should expect after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no filler. It efficiently communicates the core purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is too sparse to cover the tool's complexity. It does not mention return values, follow-up flows like verification or signing, or the consequences of creating a charter, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters already have descriptions. The description adds some meaning by mapping 'offices, amendment rules, dissolution policy' to relevant parameters (offices, amendment_board_keys, amendment_required_sigs, dissolution_grace_seconds), but it does not explain the relationship between amendment_board_keys and amendment_required_sigs or how founder keys are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'new institutional charter' and clarifies it as 'the constitutional root of an organization.' This clearly differentiates it from siblings like verify_charter and sign_charter, which perform different operations on charters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Create a new institutional charter' and 'constitutional root of an organization' clearly implies use when establishing a new organization or governance structure. However, it does not explicitly mention alternatives or exclusions, such as using verify_charter for verification or sign_charter for signing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions cryptographic signing and the included terms/revocation endpoint/MCP path, but it does not disclose what the tool returns (file content vs. writing to disk), permission requirements, or handling of the private key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no filler. The analogy to robots.txt conveys a lot of context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does not say what the tool outputs or how to handle the generated file. It also doesn't reference the sibling verify_aps_txt tool, which would help complete the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 44%, and many parameters (training, inference, mcpEndpoint, redistribution, revocationEndpoint) lack schema descriptions. The description partially compensates by indicating these are related to 'terms', 'revocation endpoint', and 'MCP upgrade path', but it does not map each parameter explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a signed aps.txt file for site-wide governance. The analogy to robots.txt plus the mention of signing and governance makes its purpose distinct from siblings like verify_aps_txt or generate_keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that this is for site-wide governance, akin to robots.txt, which implies when to use it. However, it does not explicitly mention when not to use it or point to alternatives like verify_aps_txt for validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It lists the output contents (role, tasks, instructions) but does not explicitly state that the operation is read-only, requires no special permissions, or has no side effects. The verb 'Get' implies safety, but this is left implicit rather than disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loading the verb and direct object. It is perfectly concise with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the three return components: current role, assigned tasks, and role-specific instructions. This is adequate for a parameterless self-inquiry tool, though it does not describe the structure or format of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the empty schema fully describes the input. The description adds no parameter semantics, but none are needed; per guidelines, a zero-parameter tool receives a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource: the agent's current role, assigned tasks, and role-specific instructions. This distinguishes it from sibling tools like list_tasks or get_task_detail, which focus on individual tasks rather than the agent's overall role context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as list_tasks or get_task_detail. The pronoun 'your' implies self-context, but the description does not state when this tool should be preferred or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It lists the key checks performed (validity window, grace period, supersession, challenge window) but does not disclose side effects, return values, error behavior, or how invalidity is reported. This leaves significant ambiguity for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It opens with the primary verb and resource, then lists the validation aspects in a concise, comma-separated format. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must explain return values and failure semantics; it does neither. It also omits one schema parameter (effective_at), leaving the description incomplete for a 6-parameter validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), so the description must compensate. It adds semantic meaning by connecting checks to parameters (grace period ↔ grace_until, supersession ↔ superseded_at, challenge window ↔ challenge_until), but it omits the 'effective_at' parameter entirely and doesn't clarify parameter formats beyond the minimal 'ISO datetime' notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate') and names the exact resource ('a TemporalRights object'), then enumerates the checked aspects (validity window, grace period, supersession, challenge window). This clearly distinguishes it from sibling check/validate tools that target other concerns (e.g., retention, purpose, jurisdiction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validating TemporalRights objects but gives no explicit guidance on when to choose this tool over alternatives like check_retention_expired or resolve_rights_propagation. There are no exclusions or context cues, only the inferred purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (hex sha256) and conceptual role (anchor for axis projections), but it does not mention side effects, error behavior, or input prerequisites. For a seemingly pure computation, the lack of explicit 'no state change' or failure-mode information is a gap, but the essential behavior is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence provides value: what it does, what action_ref is, and a practical use case. No fluff or redundancy makes it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It explains the purpose and output but leaves the input structure wholly undocumented, forcing the agent to guess how to form a valid action tuple. This is a significant gap for a tool that depends on precise parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (agentId, actionType, params, nonce). It only vaguely references an 'action tuple' without mapping the tuple components. The meaning of nonce, structure of params, and nature of agentId/actionType are left entirely to inference, which is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Derive the action_ref (hex sha256) for an action tuple.' This is a specific verb ('derive') and resource ('action_ref'), with additional context about it being a content-addressed anchor. It distinguishes from sibling tools like aps_construct_attribution_primitive by focusing on the hash computation rather than the full primitive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful for indexing primitives by action without constructing the full primitive.' This tells the agent when it is appropriate to use this tool, implying a niche between construction and projection. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the action 'complete' implies a mutation but does not explain permissions, side effects, reversibility, failure modes, or the structure of the proof chain. The deprecation note is useful context but does not compensate for the missing behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly scoped sentence with the deprecation notice front-loaded. Every element earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description indicates the return concept ('full 3-signature proof chain') but does not detail its shape or behavior. The parameters are well-covered by the schema, and the deprecation guidance is complete, but for a state-changing tool, the absence of side-effect and permission context leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds no parameter-specific meaning beyond what the schema already provides (e.g., intent_id provenance, status enum, summary). It does not enhance or clarify parameter semantics further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('complete') and identifies the resource ('a permitted action') plus the key output ('full 3-signature proof chain'). It is clear about the core function, though it does not explicitly differentiate itself from the sibling tool 'complete_task' beyond the proof-chain detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as deprecated and provides a direct alternative ('use gateway.aeoess.com REST API'). This gives unambiguous when-not-to-use guidance and names a replacement, exceeding typical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the principal receives its own Ed25519 keypair, which is a useful behavioral trait. However, it does not mention side effects like persistence, irrevocability, or permission requirements, leaving some key behaviors undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no redundant information. Every phrase adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 clarify return values. It mentions the keypair generation, which implies an output, but does not specify the response format or any side effects like record creation. Given the tool's complexity and lack of annotations, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter meaning beyond the schema, and the mention of 'human or org' loosely maps to display_name but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a principal identity and specifies it is for humans or organizations behind agents. It also distinguishes from sibling tools by mentioning the Ed25519 keypair, making its purpose 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('human or org behind agents') but does not explicitly state when to use this tool versus alternatives such as create_delegation or create_agent_context. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action 'Generate' without mentioning side effects such as whether the keypair is persisted, whether the private key is displayed once, or any security implications. The agent lacks information about what happens after generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous words. It front-loads the action and resource, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with no parameters, there is no output schema and the description does not mention what the tool returns (e.g., whether it returns the keypair, stores it, or only provides a reference). Without this, the agent cannot anticipate the tool's output or side effects. The description covers the 'what' but not the 'what happens next,' leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the schema is empty. According to the rubric, a baseline of 4 applies for zero-parameter tools since there are no parameter semantics to clarify. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('Generate') and a precise resource ('Ed25519 keypair') with a clear purpose ('for agent identity'). This distinguishes it from related sibling tools like rotate_key and verify_rotation_chain, which handle key lifecycle operations rather than initial generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'for agent identity,' suggesting this is for creating a new identity keypair. However, it does not explicitly state when to use this tool over alternatives (e.g., rotate_key for rotating an existing key) or provide any exclusions. Usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavior. It does reveal a key behavior: the scope is limited to agents 'endorsed by the current principal,' which is useful context. However, it does not describe the output format, whether the status is real-time or cached, or any other behavioral traits. The read-only nature is implied by 'Get status' but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the verb 'Get' and the resource. There is no wasted language or redundant information. It is concise and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description is minimally viable. However, since there is no output schema, it would be helpful to describe what the 'status' includes (e.g., online/offline, current task, last seen). The description is brief and leaves some ambiguity about the return value, though the tool's purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (vacuously). Per the rubric, 0 parameters results in a baseline score of 4. The description correctly includes the scope ('endorsed by the current principal') which adds context beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get status of all agents endorsed by the current principal.' It uses a specific verb ('Get') and specifies the resource ('status of all agents'), with the scoping detail 'endorsed by the current principal.' This distinguishes it from sibling tools like list_profiles or list_agents, which focus on listing entities rather than their status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool compared to alternatives, such as list_profiles or get_task_detail. It only states what the tool does, leaving the agent to infer when it is appropriate. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions 'multi-hop with cycle detection,' which adds insight into the traversal behavior and safety against cycles. However, it does not state whether the tool is read-only, what happens when a cycle is detected (e.g., error vs. truncation), or what the response format looks like. This is a moderate disclosure but leaves key behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core function, and avoids unnecessary filler. Every word contributes meaning: 'full derivation chain' defines scope, 'multi-hop' and 'cycle detection' add behavioral insight. This is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should ideally explain return values and side effects. It does not describe what the resolved chain looks like (e.g., a list of nodes, path, metadata) or behavior on cycles. The tool has moderate complexity (multi-hop traversal), and the description leaves some gaps, though it is sufficient for a basic understanding of the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema; it does not mention the required derivativeId or the optional maxDepth. The schema already explains maxDepth's default, so the description does not need to compensate, but it also does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves the full derivation chain for an artifact, using the specific verb 'resolve' with a clear resource ('derivation chain'). It conveys a read/trace function, distinguishing it from sibling tools like create_artifact_provenance and create_derivation_receipt, which are creation operations. However, it does not explicitly name a sibling alternative or emphasize that it is a query operation, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to trace the complete lineage of an artifact. It does not explicitly mention exclusions or alternatives, but the wording 'full derivation chain' and 'multi-hop' conveys the intended scenario clearly. It lacks explicit 'use this instead of X' guidance, which would warrant a 5, but the context is clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the mechanism ('using aps.txt path overrides') but does not mention return format, error behavior, or side effects. This is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key qualification without any wasted words. It is an excellent example of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with only two parameters and no output schema, so the description is mostly adequate. However, it does not explain what 'resolve governance terms' returns or how the result is structured, which is a notable gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (path and apsTxt) with 100% coverage. The description adds the term 'path overrides', which gives a small amount of extra context about apsTxt's role, but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Resolve') and a distinct resource ('governance terms for a specific URL path'), making it easy to distinguish from related sibling tools like resolve_authority and resolve_lineage. The mention of 'aps.txt path overrides' further narrows the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific URL path' provides clear context on when to use this tool, but it does not explicitly name alternatives or give when-not-to-use guidance. Among a large set of governance tools, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It states that the tool performs a cryptographic signature check, which subtly indicates a read-only validation, but it does not mention return values, error behavior, or side effects. This is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and a direct elaboration. It is concise, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description is adequate but not complete. It lacks explicit return value semantics and usage guidance, but the tool's simplicity reduces the need for extensive documentation. Gaps include what the tool returns (e.g., boolean, verification result) and when to choose this over other verify tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter 'endorsement_id' with a clear description. The tool description adds context that the endorsement is from a principal to an agent, reinforcing the parameter's meaning. Given 100% schema coverage, the description does not need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: verifying a principal's endorsement of an agent. It includes the specific mechanism ('Checks cryptographic signature'), distinguishing it from sibling verification tools like verify_delegation or verify_issuer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (verifying an endorsement) but does not explicitly state when to use it versus other verification tools, nor does it provide exclusions or prerequisites. It relies on the tool name and common sense rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal that the tool signs an action statement, returns a challenge and hash, and is part of binding gateway policy evaluation. However, it does not state whether the operation is non-mutating, idempotent, or whether specific permissions or key formats are required beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus a search keywords line. It front-loads version and protocol context, clearly states the action and return values, and ends with useful search tags. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters with nested objects and no output schema, so the description must compensate. It provides the purpose, return fields, and usage context, but does not explain the structure of the challenge, error conditions, or how to handle the signing keys. The info is sufficient for a basic understanding but not fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is moderate (71%), not high enough to avoid additional parameter guidance. The description only references the 'action' parameter via 'signed canonical action statement' and does not explain optional parameters like validity_seconds or required_policy_freshness, leaving a gap for these self-explanatory but undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Sink issues a signed canonical action statement' and returns the SinkChallenge and its challenge_hash. This clearly identifies both the function and outcome, and the tool name 'issue_challenge' plus context 'capability-token sink challenge (M1)' distinguishes it from sibling tools like aps_capability_evaluate_authority or aps_capability_sign_effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual usage: it is used in capability-token flow step M1 to 'bind the gateway's later policy evaluation to a specific action the sink authored.' This implies when to use the tool (as a precursor to gateway evaluation) but does not explicitly mention when not to use it or name alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return behavior ('Returns null if permitted, or escalation details if tier is insufficient') but does not mention side effects, authorization requirements, or error behavior. This is more transparent than a bare mutation description but still leaves key behaviors unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the action and quickly states the output. No filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema. The description explains the core logic and return value abstractly ('null if permitted, or escalation details'). It does not clarify how tier levels map to autonomy/spend or what escalation details contain, but for a focused check tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having its own description. The tool description reinforces the role of requestedAutonomy and requestedSpend but adds no new parameter-level detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the specific verb+resource: 'Check if an agent's earned tier permits an action at a given autonomy level and spend amount.' It clearly distinguishes this tool from sibling permission-check tools by naming the tier-checking purpose and the two key inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear from the description (checking tier permissions), but there is no explicit guidance on when to use this versus alternative checks like check_purpose_permitted or check_usage_permitted. Exclusion criteria are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the gate 'checks terms' but does not disclose side effects, permissions, reversibility, or what happens when terms are not met. The deprecation note adds context but does not compensate for the lack of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the deprecation notice front-loaded. It is concise, relevant, and every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter, fully described) and no output schema, the description provides sufficient purpose and usage context. It falls short of a 5 because it does not mention the effect of the 'mode' parameter or any return value, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'mode', with a clear description and enum. The tool description adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('data enforcement gate') along with its purpose ('checks terms before allowing data access'). However, it does not explicitly distinguish from sibling tools like 'create_gateway', though the deprecation note provides context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative: 'use gateway.aeoess.com REST API'. Since it is deprecated, it effectively tells the agent not to use this tool and what to use instead, which is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only mentions the output's cryptographic properties (Merkle-committed, signed) but does not explain side effects, permissions, error behavior, or the practical implications of calling a deprecated tool. This is similar to the update_drive example where essential operational details were missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a deprecation prefix, containing zero wasted words. Every element either delivers the warning or states the action, making it highly concise and effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex—settlement generation—yet the description is terse. There is no output schema, no annotations, and no mention of prerequisites, validation, or consequences of using a deprecated tool. The simple string schema does not compensate for the missing operational context, leaving the agent underinformed about the practical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions (startDate, endDate, periodLabel), so the description adds no parameter-level semantics. The baseline of 3 applies because schema coverage is 100%, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Generate a Merkle-committed, signed settlement record for a period,' using a specific verb and resource. This distinguishes it from siblings like aps_verify_settlement and aps_aggregate_settlement, which focus on verification or aggregation rather than generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as deprecated and instructs to use the gateway.aeoess.com REST API instead. This provides a clear when-not-to-use directive and an alternative, satisfying the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates the tool is a query (read-only) and describes the return contents (grade, flags, evidence summary) and the meaning of grade values. However, it does not disclose potential error conditions, authentication requirements, or whether any state is modified, leaving some ambiguity for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the action and resource, the second sentence lists return elements and grade meanings. Every sentence adds value, with no filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter query tool with a well-described schema, the description is largely complete. It explains what the tool does, what it returns (grade, flags, evidence summary), and the grading scale. The main gap is the lack of context around 'partner-facing' and any error-handling behavior, but these are secondary for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'agent_id' with a clear description ('The agent ID of the passport to query'). The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the attestation grade and issuance context for a passport, which is a specific verb+resource. It further explains the return values and grade scale (0-3), making the purpose unambiguous. While it doesn't explicitly contrast with sibling tools, the unique focus on 'passport grade' differentiates it from similar tools like verify_issuer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions 'This is the partner-facing trust query,' which implies an intended audience/use case, but it does not explicitly state when to use this tool versus alternatives or any exclusions. There is no mention of prerequisites or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the read-only nature via the verb 'Get' and specifies the scope of returned data, but does not mention error behavior, existence checks, or any side effects. Adequate for a simple getter, but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It names the verb, resource, and scope in a compact manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description adequately conveys what the return includes. It could mention missing-task behavior, but that is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter, task_id, with 100% description coverage. The tool description adds no additional parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details of a specific task, enumerating the included content (evidence, reviews, deliverables). This distinguishes it from sibling tools like list_tasks (which likely lists tasks) and get_evidence (which retrieves evidence directly).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when full details of a single task are needed, but it provides no explicit when/when-not guidance or references to alternative tools. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the data source (agora/agents.json), providing useful context, but it doesn't explicitly state that the operation is read-only or free of side effects, though that is strongly implied by 'List'. Returns no information about permissions or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action, object, and source. No unnecessary words, repetition, or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is mostly complete: it names the source and the filter capability is covered by the schema. However, it doesn't describe the return format (e.g., list of objects with names), which would be useful given the lack of an output schema. Still, the tool is simple enough that the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'status_filter' with its allowed values and default, yielding 100% schema coverage. The description itself adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('registered agents') and identifies the exact source ('agora/agents.json'), which distinguishes it from sibling tools like list_profiles. Purpose is unambiguous and scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The usage is implied by the nature of the task (listing agents), but no comparisons to sibling tools or preconditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a state-changing operation (load/set) but does not mention whether existing floors are overwritten, permissions required, validation behavior, or side effects. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. Every word contributes to the understanding of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without an output schema, the description conveys the core purpose and effect. It could be more complete by adding usage context or side effects, but given the low complexity, it is reasonably adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single 'yaml' parameter with 100% description coverage. The tool description reinforces that the YAML content defines the Values Floor, but adds no further detail on expected structure or format. Baseline 3 applies since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and the resource 'Values Floor from YAML', and adds the specific purpose 'Sets the floor principles for policy evaluation.' This is specific and distinguishable from siblings like 'attest_to_floor' which implies a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is used to set floor principles for policy evaluation, implying the appropriate scenario. However, it does not explicitly exclude alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does disclose that the call builds and signs in one action, binds via hash, and is scoped. However, it omits important traits such as whether the confirmation is persisted, what the return value looks like, and the security implications of providing the owner's private key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Each sentence adds distinct value: the escalation context, the single-call build-and-sign behavior, and the technical binding/scoping details. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a signing/authorization tool with no output schema and no annotations, so the description needs to carry more weight. It explains the core mechanism, but it does not mention what the tool returns, any prerequisites (e.g., valid delegation, matching key), or what happens after the confirmation is created.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds a little extra context about scoping (per_action/per_session/time_window) and hash-binding of action_details, but the parameter meanings are mostly already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Builds the ConfirmationRequest and signs it in a single call.' It specifies the resource (OwnerConfirmation) and the context (escalation boundary for flagged actions), which differentiates it from sibling tools like generic approval/request tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this is for the escalation boundary where an owner authorizes a flagged action. It implies use when an action has been flagged and requires owner confirmation, but it does not explicitly name alternatives or exclusions relative to similar approval/signing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the concrete consequence of omitting the signature (verification failures) and implies mutation of the receipt, but it does not clarify whether the receipt is modified in place or returned, nor address private key handling or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. The first sentence establishes the tool's role, the second explains the operational consequence. Every word earns its place, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and a crucial prerequisite (verification failures without signature), but it omits return value information. Since there is no output schema, the description should ideally clarify what the operation returns (e.g., updated receipt), leaving the outcome partially ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('AttributionReceipt JSON from aps_create_attribution_receipt' and 'Hex private key of cited principal'), achieving 100% coverage. The tool description adds no additional semantic meaning beyond what the schema indicates, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'adds' and resource 'consent signature to an AttributionReceipt', clearly stating the tool's function. It distinguishes from sibling verification tools like aps_verify_attribution_consent and aps_check_artifact_citations by focusing on the signing action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: without this signature, verifyAttributionConsent and checkArtifactCitations reject the receipt. This implies the tool should be used before those verification steps, but it does not explicitly mention alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 reveals that the tool supports wildcards and hierarchical matching, which is useful behavioral context. However, it does not disclose the return format, edge-case behavior, or confirm that it is read-only, which limits transparency for a simple check tool without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and resource, and every word adds value. It states the core function and then a key capability without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description covers the primary functionality and the wildcard feature. However, it omits information about what the tool returns (e.g., a boolean or result object) and any potential error conditions. Given the simplicity of the tool, this is a noticeable gap, so a score of 3 reflects that it is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, but the description adds critical semantic detail by noting that purposes support wildcards (e.g., research:*). This goes beyond the schema's example values and clarifies how the `purpose` parameter can be formatted, enhancing the agent's ability to construct valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Check if a purpose is permitted under source terms.' This clearly identifies the tool's function and scope, and the second sentence about wildcards and hierarchical matching adds a distinguishing feature that differentiates it from sibling check tools like check_usage_permitted or check_combination_permitted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the wildcard and hierarchical matching features, but it does not explicitly state when to choose this tool over similar check tools or provide exclusions. For example, it doesn't mention that exact matching might be handled elsewhere. The guidance is implied rather than explicit, so a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It only restates the creation purpose and provides a deprecation notice; it does not disclose side effects, permissions, reversibility, or output behavior for this mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the deprecation warning front-loaded. Every word contributes value, and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The deprecation notice provides essential context for not using the tool, and the schema covers all parameters. However, with no annotations and no output schema, the description fails to mention return values or side effects, though the deprecation reduces the need for full operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description in the schema. The tool description adds no parameter-level information, but the schema fully documents the three parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('ProxyGateway enforcement boundary'), making the tool's purpose unambiguous. It also distinguishes this from related gate tools by naming the ProxyGateway resource type explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as deprecated and names the alternative ('use gateway.aeoess.com REST API'). This provides clear when-not-to-use guidance and directs the agent to the correct replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's core behavior: 'Shows the first 10 tool calls after passport issuance.' It does not mention side effects, authentication needs, rate limits, or edge cases. The additional context 'Real agents do work. Farming agents extract.' describes agent behavior, not tool behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main function, then adds context. It is concise with no obvious waste, though phrases like 'consilium signal #2' and the agricultural metaphors may be slightly cryptic for an agent. It earns each sentence's place, but could be more direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 output schema), the description covers the essential information: what it returns (behavioral sequence) and its scope (first 10 tool calls after passport issuance). It does not specify the exact return format, but for low-complexity tools this is acceptable. The context about distinguishing real vs farming agents adds interpretive value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, agent_id, is described in the schema. The description adds no additional meaning beyond stating 'for an agent,' which is already in the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the post-issuance behavioral sequence for an agent.' It specifies the exact scope ('first 10 tool calls after passport issuance'), distinguishing it from sibling tools like list_profiles or get_task_detail. This is a specific verb+resource+scope formulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 by explaining its purpose: 'Real agents do work. Farming agents extract. This is consilium signal #2.' This implies it is used to distinguish authentic agents from farming agents. However, it does not explicitly name alternative tools or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It specifies the tool returns particular content types but does not explicitly confirm read-only status, pagination, or other operational behaviors. The 'get' verb implies safety, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is information-dense and clearly states the tool's function. The second sentence is somewhat promotional but adds a conceptual hook. Overall, the description is compact and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately outlines the return categories. It does not specify response format or ordering, but for a digest-type tool this may be acceptable. The absence of an output schema is mitigated by enumerating the content types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully defines the interface. The description adds no parameter details, but none are needed; the baseline score for 0-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a personalized digest from the Intent Network and enumerates its contents (relevant matches, pending intro requests, incoming intros). This distinguishes it from sibling tools like search_matches or request_intro by highlighting its aggregative, overview-oriented purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (wanting a digest of matches and intros) but does not explicitly provide when-to-use versus alternatives or any exclusion criteria. It lacks guidance like 'use this for a daily summary instead of querying individual tools'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It proactively discloses that it reports each field of the SDK's verdict separately (e.g., 'a signature can verify while the threshold is short'), and explains that session state is not an authoritative registry: amendments live only in this process, are lost on restart, and carry no external trust. This adds meaningful transparency about output granularity and trust implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the primary purpose, and the second sentence packs essential behavioral nuance and a trust caveat. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the description covers the core behavior (field-level reporting) and the critical limitation (no persistent state). It does not cover input format or error handling, but these are relatively minor for a read-only verification tool. The description is sufficient for an agent to call it correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only types and requiredness for charter_id and amendment_id, with no descriptions (0% coverage). The description does not elaborate on these parameters, their formats, or their relationships. The names imply what they are, but the description adds no semantic value beyond inference from the parameter names and tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (verify), the resource (an amendment), and the specific context (against its charter's amendment policy). It further distinguishes itself by explaining the field-level granularity of the verdict, which sets it apart from a simple boolean check and from sibling tools like verify_charter or propose_amendment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about the field-level reporting and the ephemeral nature of amendments, but it does not explicitly direct when to use this tool versus alternatives, nor does it state when not to use it. The warning about session state being non-authoritative implies a caution, but no explicit situational guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates the tool performs read-only verification checks but does not disclose return format, error behavior, or side effects. It adds detail about the specific checks but lacks comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence that front-loads the verb and immediately states the object. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain the return behavior, which it doesn't. It also omits prerequisites or error conditions. While the schema covers parameters, the description leaves the agent uncertain about what a successful verification returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with clear descriptions, so the baseline is 3. The description adds semantic meaning by mapping the parameters to the verification concepts (signature, content hash, DID consistency), which helps the agent understand how block, content, and publicKey relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and names the resource ('governance block'), and further specifies the exact aspects verified (signature, content hash, DID consistency). This clearly distinguishes it from sibling tools like generate_governance_block or parse_governance_block_html.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verifying governance blocks but provides no explicit when-to-use guidance or mention of alternatives. It doesn't state when to prefer this over related verification tools like verify_charter or verify_delegation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two important behavioral traits: the output is a 'Signed summary' and 'no receipt history is exposed' – a notable privacy guarantee. It does not describe side effects or permission requirements, but it meaningfully goes beyond a bare mutation description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and purpose. The second sentence adds a critical behavioral caveat without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is too sparse. It gives purpose and one behavioral trait but does not explain how the signed summary is structured, what each parameter means, or how this tool relates to sibling reputation tools. The agent would need significant additional inference to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is very low (17%), and the description does not compensate. It does not explain agent_id, tier, diversity_score, gateway_private_key, or gateway_id. The phrase 'Signed summary' hints that gateway_private_key is used for signing, but that is indirect. Most parameter meanings remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'vouched reputation', and the specific purpose 'for cross-gateway portability (WS-3)'. It distinguishes this from sibling tools like update_reputation by focusing on creation for portability rather than modification or downgrading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly signals when to use this tool ('for cross-gateway portability'), giving a concrete context. However, it does not explicitly mention alternatives, exclusions, or when not to use it, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the return shape ({required, requirement?, reason?}) and the escalation-boundary nature of the check. However, it does not explicitly state whether the check is read-only, whether it mutates any state, or whether special authorization is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first sentence front-loads the core purpose, the second gives the return shape, and the third points to the related confirmation tool. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explicitly provides the return object shape. Combined with the detailed input schema, this gives enough context for the tool's usage. It lacks edge-case or error behavior, but that is not critical for this simple guard-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a helpful description (e.g., delegation, session_id, action_class, action_details). The tool description adds no parameter-level detail 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'check whether an action on a v2 delegation requires owner confirmation before execution.' It names the resource (v2 delegation) and the check semantics, and it distinguishes itself from related tools like create_v2_delegation and aps_record_owner_confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: 'before execution' of an action on a v2 delegation. It also names the relevant follow-up tool (aps_record_owner_confirmation) to clear the flag when required. It does not explicitly enumerate when not to use the tool or mention alternative check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully specifies the return values: {same_receipt: true} for success, and {same_receipt: false, reason: ...} with four enumerated reason codes for failure. Since no annotations are provided, this output disclosure carries the transparency burden, though it doesn't explicitly confirm read-only behavior or describe malformed input handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second precisely lists the output schema and reason enums. No filler, well-front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the complete output contract (since no output schema exists), covering both success and all failure reasons. It is sufficient for an agent to invoke and interpret results, though it omits edge-case behavior like invalid projection inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (projection_a and projection_b each have brief descriptions), the baseline is 3. The description adds limited value beyond restating that two projections are involved; it does not explain what constitutes a valid projection or how to format them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a cross-projection consistency check to confirm two projections originate from the same signed receipt. This specific verb-resource pairing distinguishes it from sibling verification tools that focus on single projections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have two projections that need to be checked for shared receipt origin, but it does not explicitly contrast with alternatives like aps_verify_attribution_projection or provide when-not-to-use guidance. Usage context is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly states that the tool builds and signs an object, names the axes, and says it returns the complete signed object—implying a pure construction operation with no hidden persistence. It does not disclose potential failure modes or validation requirements, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the function and names the axes, the second states the return value. There is no redundancy or filler, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with nested schemas and no output schema. The description adequately communicates the overall scope, axes names, and return value, which is enough for a well-described schema. It lacks explicit usage guidance and deeper behavioral caveats, but the core invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with detailed descriptions (e.g., action_ref derivation, axes spec reference, issuer DID, key format, timestamp default). The tool description adds no parameter-level meaning beyond the axis labels, so the baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Build and sign a four-axis AttributionPrimitive for an action.' It names all four axes (D, P, G, C), making the purpose unmistakable. It also distinguishes from sibling tools like aps_verify_attribution_primitive by emphasizing construction and signing, and notes the return value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you use it when you need to build and sign an attribution primitive for an action. However, it offers no explicit when-to-use guidance or contrast with similarly named tools (e.g., aps_create_attribution_receipt, aps_create_provisional), so the choice among alternatives is not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds meaningful detail: it discloses that the projection contains axis content plus a two-hop Merkle path, and explains the cryptographic purpose. It does not fully describe the return format or error behavior, but this is a simple read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the first sentence stating the core operation. The remainder adds essential behavioral details and the axis enum without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a straightforward extraction tool: it identifies inputs, output contents, and downstream use. There is no output schema, but the description adequately covers the key return aspects, though it could mention the exact return type or structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description merely mirrors the schema by listing axis values and referring to aps_construct_attribution_primitive for the primitive parameter. No additional parameter semantics are added beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Extract') and identifies the exact resource ('AttributionPrimitive'), making the action unambiguous. It also distinguishes the tool from siblings like aps_verify_attribution_projection by describing the projection's content and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining that the projection is for downstream verification, but it does not explicitly state when to prefer this over alternatives or provide exclusions. No sibling tool is mentioned, unlike the get_calls exemplar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context by explaining that the tool constructs projections for all four axes before verifying, but it does not mention potential side effects, error behavior, or return format. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb 'verify,' and free of unnecessary detail. It efficiently conveys purpose and usage without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter verification tool with no output schema, the description covers purpose, usage, and key behavioral details. The only gap is that it does not indicate what the tool returns (e.g., boolean, result object), but the overall context is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds some context by referring to 'full' primitive and 'four axes,' but it does not clarify the expected type/structure of the primitive parameter beyond what the vague schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'End-to-end verify of a full AttributionPrimitive' and specifies it constructs projections for all four axes. It uses a specific verb and resource, and distinguishes itself from sibling tools like aps_verify_attribution_projection by emphasizing 'full' verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'post-construction sanity check' and 'verifying a primitive received from a peer.' However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It discloses the internal verification logic in detail, but it omits the return behavior (e.g., boolean, throw) and side effects (likely read-only but not stated). The term 'verify' implies a non-mutating check, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action 'verify'. The parenthetical list is dense but each item is meaningful and directly supports the purpose. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly explains what is verified, but because there is no output schema, it leaves out what happens on success or failure (e.g., returns boolean, raises exception). For a verification tool, this behavioral outcome is important context. Still, the core operation is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with short descriptions for both parameters, giving a baseline of 3. The tool description adds semantic context by enumerating the criteria checked, which clarifies how 'statement' (PromotionEvent) and 'policy' are used together. This adds value beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'verify that a promoted statement's PromotionEvent cryptographically satisfies the PromotionPolicy'. It lists concrete checks (policy_reference match, promoter in required_signers, threshold, signature, max_time_to_promote, author-signature tamper check), distinguishing it from other verify tools like aps_verify_attribution_consent or verify_delegation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Commitment boundary' provides clear context for when this tool is used, implying it is the validation step after promotion. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the data source (reads from a JSON file) and implies a read operation. However, it doesn't explicitly state that setting mark_read=true can modify state, nor does it describe the return format. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and backed by a data source. No wasted words and the structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and data source, which is adequate for a simple message-checking tool. It doesn't explicitly state what the tool returns, but with no output schema the return value is fairly obvious from context. Overall, it's complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (mark_read, unprocessed_only) are fully described in the schema with defaults and coverage at 100%. The tool description adds no parameter-specific guidance, but the schema already provides sufficient semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking messages addressed to the agent. It specifies the resource (messages addressed to you) and the data source (comms/to-{your-agent-name}.json), which distinguishes it from siblings like send_message or get_agora_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to read personal messages addressed to you. It doesn't explicitly mention alternatives or exclusions, but the scope is unmistakable when compared to siblings like send_message or broadcast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses a key behavioral trait—automatic routing through the 3-signature policy chain—but does not mention auth requirements, return values, reversibility, or the global scope implied by 'every action.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with the critical deprecation notice front-loaded. It contains no filler and earns its place by conveying purpose and the most important usage caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no output schema, and no annotations, yet the description only covers purpose and one behavioral trait. It omits what the caller should expect in return, whether creation activates the context immediately, and any side-effect warnings needed for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured data already documents all five parameters, including defaults and enums. The description adds no parameter-specific guidance, keeping this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Create an enforcement context' and adds a specific behavioral qualifier—'automatically runs every action through the 3-signature policy chain'—which distinguishes it from generic create tools like create_policy_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as deprecated and directs users to an alternative: 'use gateway.aeoess.com REST API.' This provides a clear when-not-to-use signal and names a specific replacement, satisfying the highest usage-guideline bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the function and deprecation. It does not disclose behavioral details such as whether it's read-only, response format, or any side effects. Although 'Get' implies read-only, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the deprecation warning and clearly states the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is deprecated, and the description provides sufficient context: the agent can immediately understand not to use it and to use the external REST API instead. Given no params and no output schema, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 in schema), so the description has nothing to explain. The schema coverage is trivially 100%. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Get gateway statistics') with a verb and resource, and includes a deprecation notice. However, it does not distinguish this tool from sibling tools beyond the name, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is deprecated in v3.0.0 and directs users to the gateway.aeoess.com REST API instead, providing a clear exclusion and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool lists topics with message counts, giving a basic understanding of the return content. However, it does not disclose any possible pagination, sorting, or other behavioral traits. For a 'list' operation this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 contains no extraneous words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description adequately states what it does and what it returns. However, without an output schema, it could be slightly more explicit about the structure of 'topics' (e.g., IDs, names) and whether pagination exists. Still, it is mostly complete for a simple list action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema is trivially sufficient (schema coverage 100% or vacuous). With zero parameters, the baseline is 4, and the description correctly does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a resource 'topics in the Agora feed' and adds 'with message counts' which clearly differentiates it from sibling tools like get_agora_thread or get_agora_by_topic. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a full topic list is needed but provides no explicit guidance on when to use this tool versus alternatives such as get_agora_thread or get_agora_by_topic. No exclusions or alternative tool names are mentioned, so the guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It does convey that the tool lists records and exposes session-level counts and trust posture, implying a read-only operation. However, it does not explicitly state the absence of side effects, or mention ordering, pagination, or potential volume, leaving some gaps in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The first sentence front-loads the core action and object, the second adds relevant detail about the returned data, and the third gives a practical use case. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the main aspects: what is listed, what information is shown, and a suggested use. There is slight ambiguity between 'all stored issuance records' and 'in this session', but overall the description is sufficient for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage by triviality), so the baseline is 4. The description adds value by explaining the kind of data returned, even though there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'List all stored issuance records with their passport grades', using a specific verb and resource that clearly distinguishes the tool from sibling list tools like list_profiles and list_tasks. It also specifies the data shown (passport grades, counts, trust posture), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for monitoring issuance patterns' gives a clear use case, but it does not explicitly state when not to use this tool or mention alternatives. For a simple zero-parameter listing tool, the guidance is adequate but not as strong as explicit when-to-use versus when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does reveal that the tool searches for specific tags (script or meta), which is useful. However, it does not describe the return format, potential failures (e.g., no governance block found), or whether it extracts multiple blocks or just one. This is moderately transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly to the point, with no superfluous information. It front-loads the primary action and then clarifies the extraction targets, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter parsing tool with no output schema, the description covers the essential purpose and mechanism. It could be enhanced by describing the output format or edge-case behavior, but given the simplicity and self-explanatory nature, the existing description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single 'html' parameter with description 'HTML content to parse'), so the schema already fully documents the parameter. The tool description adds no additional semantic context beyond what the schema provides, landing at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Extract') and resource ('governance block from an HTML page'). It also specifies the mechanism ('Looks for APS governance script tags or meta tags'), which distinguishes it from sibling tools like generate_governance_block or verify_governance_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have HTML content and need to extract a governance block. It does not explicitly exclude alternatives or name sibling tools, but the action of parsing HTML is distinct from generation or verification, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits itself. It indicates the action is scoped to 'your' card and operates within the Intent Network, but it does not disclose whether the removal is reversible, triggers side effects, or requires special permissions. This leaves some gaps but is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the action and the usage condition. It wastes no words and is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with one parameter and no output schema, the description adequately covers the what and when. It might mention potential effects (e.g., if removal invalidates related data), but given the tool's simplicity, the information provided is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter card_id, with a clear description 'Card ID to remove'. The tool description adds no extra parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes the user's IntentCard from the Intent Network. The verb 'Remove' and resource 'IntentCard' are specific, and it distinguishes itself from sibling tools like create_intent and evaluate_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool ('Use when your needs or offers have changed'), giving clear context. However, it does not mention alternatives or when not to use it, so it lacks the full exclusions found in a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the core behavior: approving shares your disclosed information, declining does not. However, it is ambiguous whether 'your disclosed information' refers to all previously disclosed data or only the fields listed in disclose_fields. The optional disclose_fields parameter's effect on approval isn't clarified, so the behavioral transparency is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose, and every word earns its place. There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a 100% schema-covered parameter list and no output schema, the description is largely sufficient. It covers the primary action and outcome. However, the interaction between approved and disclose_fields is left ambiguous, and the description doesn't state what happens to the intro request after the response, leaving a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 well-documented. The description adds no additional meaning beyond the schema; it only refers vaguely to 'disclosed information,' which maps to disclose_fields but without further detail. Therefore the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Respond to an introduction request.' It also clarifies the two actions (approve/decline) and distinguishes this tool from siblings like request_intro, which handles the other side of the process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you have an introduction request to respond to. It doesn't explicitly mention exclusions or alternatives, but the purpose is well-scoped and no sibling duplicates this functionality, so a slightly lower but still strong score is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 reveal key behaviors: planned mode with configurable overlap (default 24h), emergency mode with immediate old-key retirement, and that it returns revocation results. However, it does not disclose potential side effects like cascading delegation revocation (though hinted via 'revocation results') or any permission requirements, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence summary that front-loads the primary purpose, then explains the two modes, and finally lists return values. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description covers the core behaviors and return values. It explains both modes and mentions revocation results, but it lacks details on prerequisites, default behavior of optional parameters beyond what schema shows, and explicit side effects. Still, it is reasonably complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the baseline is 3. The description adds slight context to activation_delay_hours (default 24h) and mode semantics, but these are already well-described in the schema. It does not significantly enhance understanding of parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Rotate an agent's Ed25519 key.' It distinguishes from siblings like verify_rotation_chain or generate_keys by focusing on rotation and specifying two modes (planned/emergency) and return values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each mode (planned for configurable overlap, emergency for immediate retirement) but does not explicitly compare with alternatives or state exclusions. There is no mention of when to prefer this over other key-related tools, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the ranking is based on multiple criteria and that results are drawn globally, but it does not explicitly state read-only semantics, output format, or any limits beyond the parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is front-loaded with the action and resource, and every clause adds value (scope, ranking, criteria). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with fully documented parameters and no output schema, the description provides sufficient context about its purpose and matching behavior. It could mention the output shape, but the schema and simplicity make it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the description need not add parameter details. The description does not reference the parameters directly, but the schema handles their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Search the Intent Network') and outcome ('ranked matches from all agents worldwide'), using a specific verb and resource. It distinguishes from a simple list by emphasizing ranking and relevance criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding relevant people based on need/offer overlap, tag similarity, and budget compatibility, providing clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the specific relevance-focused purpose differentiates it from general profile listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 two key behaviors: the message is signed, and it is written to a specific file path. This is a meaningful level of transparency for a simple mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, rich parameter schema, and lack of output schema, the description covers the essential aspects: action, target, and side effect. Minor gaps like prerequisites or error handling exist but are not critical for a messaging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already described. The tool description adds only the context that the 'to' parameter is used in the file path, offering marginal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send'), a clear resource ('signed message to another agent'), and the concrete side effect ('written to comms/to-{agent}.json'). This clearly distinguishes it from sibling tools like broadcast or post_agora_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for direct agent-to-agent communication but does not explicitly contrast with siblings like broadcast or post_agora_message. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose several behavioral aspects (what integrity checks are performed: content hash, signatures, office consistency, incompatibility) but does not state whether the operation is read-only, what it returns, or any permissions required. The term 'Verify' implies a read operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Verify a charter's integrity') and immediately lists specifics. Every word adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema, no annotations). The description explains what the tool does and highlights key integrity aspects, but it does not describe the return value format or provide more detail on ambiguous terms like 'incompatibility'. While this is a fairly complete description for a verification tool, the lack of any output or behavioral detail prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with charter_id described as 'Charter ID to verify'. The tool description adds context about what the verification checks but does not elaborate on the parameter format, accepted values, or how the parameter relates to the checks. Thus, it adds minimal value beyond the schema, aligning with baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Verify' and clearly defines the resource as 'a charter's integrity' with a detailed list of check types: content hash, signatures, office consistency, incompatibility. This distinctively separates it from siblings like create_charter or sign_charter, which likely have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used when a charter's integrity needs to be validated, and lists specific aspects to check. However, it does not explicitly mention when not to use it or provide alternative tool names, so it lacks explicit exclusions or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return value (true if valid) but does not explicitly state whether the operation is read-only, how errors are handled, or what happens with malformed input. The verb 'verify' implies non-mutation, but side effects are not explicitly ruled out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes the return value. Every word contributes to the core meaning, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with one parameter and a boolean return, the description covers the essential behavior. The schema documents the input structure, and the return behavior is stated. It could mention error cases or prerequisites, but the tool is simple enough that the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter did_document, which is described as a 'RotatableDIDDocument JSON object with rotationLog'. The tool description adds minimal extra semantic meaning beyond referencing the rotation log, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Verify' and clearly identifies the resource as 'all rotation signatures in a DID document's rotation log'. It also states the expected return value, making the tool's purpose unambiguous and distinct from sibling verification tools like verify_charter or verify_governance_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for validating the cryptographic integrity of a DID's rotation chain. However, it does not explicitly mention when to use it over alternative verification tools or list any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains internal steps (per-axis totals, balanced-Merkle commitment, residual buckets) and the output format (fully signed record), giving agents a good understanding of what the tool does without side effects being hidden. It stops short of explicitly stating safety or side-effect status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. Four sentences cover the main action, internal processes, and output. Each sentence adds useful information, though it could be slightly tighter without losing essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested objects and no output schema, but the description explains the output type and high-level structure (axes, commitments, residual buckets). It also references a spec file. It does not elaborate on the receipts array elements or prerequisites, but overall it gives sufficient context for a capable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for all parameters (80% coverage), including period semantics and gateway fields. The description adds context about the period being half-open and the signed output, but it does not deepen parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with a specific verb ('Aggregate') and resource ('Attribution Primitives' into a 'SettlementRecord'). It also details the half-open period, axis outputs, and residual buckets, making it distinct from siblings like aps_verify_settlement or generate_settlement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by describing the input, process, and output, implying when to use it (for batch aggregation of primitives into a signed settlement). It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing that it returns a null value for no-share contributors and that the response includes the full signed record and per-axis data. It also mentions the trust property (verifiable without trusting the gateway), adding behavioral context. It omits any mention of side effects or permissions, but as a query-building tool, no mutations are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action. It includes all essential details without redundancy, though a slight split into two sentences could improve readability. It remains concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately specifies the return values (total_weight, contribution_count, merkle_path, axis_root, full signed record) and the null case. It explains the end-to-end verification use case. It doesn't cover all potential error conditions, but given the modest complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full (100%) description coverage for all three parameters. The description adds minimal extra meaning beyond the schema, only confirming the role of record and contributor_did. This meets the baseline of 3, as the schema already provides the necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ("Build") and a specific resource ("contributor-query response"). It distinguishes itself from sibling tools by detailing the exact input (signed SettlementRecord and contributor DID) and output (per-axis fields plus the signed record), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: use this when you have a signed SettlementRecord and need a contributor's share verification data. It explains the output and the null case, which guides the agent on when to call it. However, it does not explicitly mention alternatives or when not to use it, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the nullifier replay rejection, token consumption, action execution, and signing of the EffectReceipt binding token to result. This goes beyond what the schema or name alone would convey, though it does not mention reversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences plus search keywords. It is front-loaded with the version and role, and every sentence adds value—protocol position, behavior, and attestation context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 clarify what the tool returns. It says 'signs an EffectReceipt' and mentions the attestation tuple, implying the receipt is the output, but it never explicitly states the return value or error cases beyond nullifier replay. For a complex protocol tool with 7 parameters, this leaves a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, with challenge, challenge_receipt, and gateway_public_key already described. The description adds protocol context (M3 preimage, M1 binding) but does not explicitly explain sink_private_key, sink_public_key, or the effect object structure beyond what the schema already shows. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'consumes the token preimage', 'executes the action', and 'signs an EffectReceipt'. It clearly identifies this as the M4 sink step in the capability-token protocol, distinguishing it from sibling tools like aps_capability_issue_challenge and aps_capability_mint_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear protocol sequencing: it must be invoked after the gateway's M3, consuming the token preimage from that step. It references the (M1, M3, M4) tuple, which implies the prerequisite context. However, it does not explicitly state alternatives or when not to use this tool, so it misses the full top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a critical trait: the receipt is not yet valid and requires consent from the cited principal. This goes beyond a generic 'create' description and adds meaningful state information, though it omits details like persistence, return value, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two sentences, front-loaded with the primary purpose and followed by a crucial caveat. Every sentence contributes information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 9 parameters and no output schema, so the description should compensate by outlining expected return values or receipt format. It explains the validation lifecycle well but does not describe what the tool returns or the full structure of the receipt, leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds no additional meaning about the parameters themselves, aligning with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('build'), a concrete resource ('AttributionReceipt'), and key scope ('citer-signed', 'attributing a claim to a third-party principal'). It also distinguishes itself from siblings, notably aps_sign_attribution_consent, by explicitly contrasting the receipt's validity state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use the tool: to create an attribution receipt that is not yet valid, with a follow-up consent signature via aps_sign_attribution_consent before checkArtifactCitations accepts it. It provides workflow context but does not explicitly list alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core mechanism (attaching a PromotionEvent satisfying m-of-n signatures) and a key edge case (dead_man_elapsed auto-withdraws). However, it does not mention permissions, reversibility, side effects, or return behavior, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'Commitment boundary:' and zero redundant wording. It efficiently covers purpose, mechanism, and an exclusion in a compact, well-structured form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good context for the core operation and leverages the schema's parameter descriptions. However, since there is no output schema, the description does not explain return values, error cases, or post-promotion behavior (beyond 'binding'). It also omits prerequisites such as needing a valid provisional statement, aside from what is inferred from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the relationship between promotion_event and policy ('m-of-n principal signatures') and by clarifying that dead_man_elapsed is an invalid state. This helps the agent understand how to construct valid parameters beyond the terse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'promote a provisional statement to binding by attaching a PromotionEvent that satisfies the PromotionPolicy (m-of-n principal signatures)'. It uses a specific verb (promote) and resource (provisional statement), and the scope (to binding) is explicit. It distinguishes itself from sibling tools like aps_create_provisional and aps_withdraw_provisional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage boundary by stating 'dead_man_elapsed cannot promote — it auto-withdraws via the dead-man path.' This gives an explicit when-not condition. However, it does not name an alternative tool (e.g., aps_withdraw_provisional) for the dead-man path, so it falls short of fully explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the issuer's Ed25519 private key signs the canonical JCS form, a non-obvious technical detail affecting the output. It also states that the tool returns a signed object, implying no side effects. Could mention security handling but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the main action, and the second efficiently describes the return value and the signature mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no output schema or annotations. The description clarifies the return value's purpose but does not describe the certificate structure or error conditions. The schema's field descriptions help, but the description alone leaves gaps around how parameters relate to the signed object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all 13 parameters documented, so the baseline is 3. The description adds some context by explaining the issuer private key's role in signing the JCS form, but does not meaningfully expand on the other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase 'Build and sign' and names the resource 'mutual-auth certificate' with the target 'agent or information system'. This clearly distinguishes it from sibling tools like mutualAuthVerifyTrustBundle and mutualAuthDeriveSession, which focus on verification and key derivation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the certificate is 'ready to carry into a handshake', giving clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the purpose of building a cert before a handshake is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the safety/behavioral burden. It discloses that signatures are ignored and that the computation is canonical (sha256), which explains key input handling and determinism. It doesn't cover errors or return format, but for a simple hash helper this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action ('compute'), no redundant phrasing. Every clause carries meaning about purpose, behavior, or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter compute tool with no output schema and no annotations, the description explains what it does, why it exists, and key input behavior. It could specify the return type (e.g., hex string) but that's implied by 'sha256 id' and not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'receipt' parameter as 'AttributionReceipt JSON (signatures ignored)' with 100% coverage. The description adds 'unsigned core' but that is semantically equivalent to the schema's note, providing no extra value over structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('compute'), identifies the resource ('canonical sha256 id of an AttributionReceipt's unsigned core'), and distinguishes itself from sibling tools by focusing on id generation for tamper detection, not receipt creation or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly positions the tool as a helper for verifiers to detect id tampering, implying when to use it. It doesn't explicitly name alternatives or exclusions, but the use case is concrete enough given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 reveals key behaviors: default non-binding, promotion condition via PromotionPolicy, and dead-man expiry auto-withdrawal. It lacks details about persistence or return behavior, but the disclosed lifecycle semantics are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense, front-loaded sentences with no filler. The opening 'Commitment boundary' provides framing, and each subsequent sentence adds essential lifecycle information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lifecycle-driven provisional commitment tool, the description covers the core purpose, non-binding default, promotion trigger, and expiry behavior. It could be improved by referencing sibling tools for promotion/withdrawal and clarifying the return value, but the schema covers parameter details fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 description adds contextual meaning around dead-man expiry and promotion policy, but it does not provide parameter-level detail beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'emit a provisional statement for agent-to-agent negotiation' with a specific verb and resource. It further distinguishes itself by explaining 'non-binding until a PromotionEvent satisfies a PromotionPolicy,' setting it apart from final/promotion-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: for non-binding, provisional statements in agent-to-agent negotiation. It implies exclusions (e.g., not for binding commitments) but does not explicitly name alternatives like aps_promote_statement or aps_withdraw_provisional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses type-specific freshness behavior, including the static case which is not evident from the schema. However, it does not describe return values or error handling, though the predicate-style name suggests a boolean outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the primary verb and resource front-loaded. Each clause delivers distinct type-specific information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core type-specific logic. No output schema exists, and while return values are not explicitly stated, the tool name clearly implies a boolean result. A brief note about true/false semantics would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover the conditional requirements for ttl and max_age, and the description largely restates these. The only new semantic addition is 'static: always fresh', which is minimal, so the baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and resource ('typed attestation evidence'), and the type-specific rules distinguish it from sibling tools like get_evidence or review_evidence. The verb is specific and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditional logic for when parameters are required based on the evidence type ('rotating: ttl required; snapshot: maxAge optional; static: always fresh'). It does not explicitly mention alternative tools, but the context strongly implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is only a convenience check and that gateway enforcement is authoritative, which is a meaningful behavioral caveat. It implies a read-only operation ('Check'), but does not explicitly state side-effect freedom or error behavior, leaving a slight gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value. It is concise and easy to scan, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter boolean check, the description covers the core function and a key caveat. However, it does not explicitly state the return type (though 'is_' implies boolean) or explain what 'currently authorized' means in terms of DID document semantics, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for both parameters, so the baseline is 3. The description mentions 'public key' and 'DID document' but adds no further semantic detail beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and a clear resource: 'a public key is currently authorized for active operations in a DID document.' It clearly distinguishes this from sibling tools like rotate_key or verify_rotation_chain, which deal with key rotation rather than active authorization status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'SDK convenience check; gateway enforcement is authoritative' provides clear context that this tool is a lightweight helper and not the final authority, advising against using it for enforcement decisions. However, it does not explicitly name an alternative tool or specify when-not-to-use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently reveals that the server silently captures Tier 0 observed signals, computes a passport grade (0-3), and produces keys/signed passport/attestation summary. It also notes the lack of npm install, implying a server-side operation. It could mention persistence or auth requirements but still provides substantive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main verb and object, followed by behavioral details and usage guidance. Every clause adds meaningful information without redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description enumerates the key outputs (keys, signed passport, attestation summary, grade) and provides usage context. It also gives enough indication of the tool's role within the larger system (onboarding). It could elaborate on side effects or prerequisites, but for a straightforward issuance tool with well-schematized parameters, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with clear descriptions for all 5 fields. The description adds minimal parameter meaning—only loosely referencing 'optional values floor' which maps to attest_to_floor. Since the schema already documents all parameters, the description's added value is marginal, consistent with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Issue') and a clear resource ('complete agent passport'), listing concrete components (keys, signed passport, attestation summary, optional values floor). It distinguishes itself from sibling tools by emphasizing 'in a single call' and 'onboard any agent,' which sets it apart from query/verification tools like get_passport_grade or generate_keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to onboard any agent — no npm install required.' This tells the agent when to use the tool. However, it doesn't explicitly state when not to use it or mention alternative tools for partial steps (e.g., generate_keys), missing full exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the core behavior (listing filtered tools) and the wildcard behavior, but does not explicitly state that this is a read-only operation with no side effects, nor describe the return format. The provided scope list adds useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: the first defines the purpose, the second explains usage, and the third lists accepted values. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no nested objects, no output schema), the description is largely complete for invocation. It could be slightly enhanced by mentioning the return type or that it is safe/read-only, but the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'scopes' parameter, but the description adds significant value by enumerating all valid scope values and the wildcard option. This goes beyond the schema, which only provides a generic example, and compensates for the lack of enums in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available MCP tools filtered by delegation scope, with a specific verb ('List') and resource ('available MCP tools'). This distinguishes it from sibling tools like list_tasks or list_profiles, which list domain-specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('Pass your delegation scopes to see which tools you can use') and enumerates valid scope values, including a wildcard for all tools. It does not explicitly mention alternatives, but the tool's unique purpose and scope-filtering mechanism make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explicitly states the return values (ok:true on success) and enumerates possible failure reasons (untrusted_publisher, signature_invalid, bundle_expired, not_yet_valid), which gives good insight into expected behavior without revealing internal mechanics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and every sentence provides necessary information. There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, required inputs, and return behavior, which is enough for an agent to invoke it correctly. It does not detail the structure of TrustAnchorBundle or the output format, but given the absence of an output schema, the information provided is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters, so baseline is 3. The description adds minimal contextual value by calling the public keys 'root configuration', but it does not materially enrich understanding of 'bundle' or 'now_ms' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the specific resource 'TrustAnchorBundle signature and freshness', making the tool's purpose unambiguous. It also distinguishes this from sibling verification tools like mutualAuthVerifyAttest by explicitly naming the TrustAnchorBundle resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying that the caller supplies trusted publisher public keys (root configuration), which indicates when this tool is appropriate. It does not explicitly list alternatives or exclusions, but the context is sufficient for an agent to select this tool over other verification siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses key behavioral traits: supplies full replacement (not patch), SDK derives preimage and signs, and crucially, session state is not authoritative—amendments are ephemeral, lost on restart, and carry no external trust. This is exceptional transparency about side effects and trust implications, well beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly written sentences, each adding distinct information: purpose, replacement semantics, signing process, and ephemeral/trust limitation. The main purpose is front-loaded, and there is zero filler. Ideal conciseness with high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover what an agent needs to invoke it. It tells the agent that a full CharterCore is required, that the SDK signs, and that the result is not persistent. It lacks an explicit statement about response format or that the charter_id must reference an existing charter, but these are not essential for a correct call. The description is nearly complete for a proposal tool in a complex domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (4 of 6 parameters have descriptions). The description adds context about the SDK deriving the signing preimage and producing the proposer signature, which relates to the key parameters but does not explicitly explain proposer_private_key or proposer_public_key beyond their presence. It does clarify proposed_charter is a full replacement. With coverage above 50%, baseline is 3; the description provides marginal added value but does not fully compensate for undocumented key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool proposes an amendment to a charter, specifies the resource (charter) and action (propose). It distinguishes from sibling tools like create_charter and sign_amendment by emphasizing it supplies a full replacement CharterCore, not a patch, and that the SDK produces the proposer signature. This uniquely identifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—proposing an amendment—but does not explicitly state when to use this tool over alternatives like sign_amendment or verify_amendment. It mentions the tool provides a full replacement, which hints at a choice, but lacks direct exclusions or cross-references to siblings. Context is clear but no explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key non-obvious behavior: both sides must approve before real information crosses. This goes beyond the schema and helps the agent understand the workflow. No annotations are present, so the description carries the burden, and it does so effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by the key behavioral note. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a request tool with 4 parameters and no output schema, the description explains the purpose and the approval workflow sufficiently. It lacks detail on what the tool returns or failure states, but the core context is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter individually described. The tool description does not add any extra meaning to the parameters (e.g., relationships or restrictions). Baseline 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Request') and identifies the resource ('an introduction to another agent's human') plus the precondition ('based on a match'). This clearly differentiates it from sibling tools like respond_to_intro and search_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use: after finding a match, and it notes the two-sided approval requirement. However, it does not explicitly mention alternatives like respond_to_intro or when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the verification method (cryptographic check against public key) and an important edge case ('Returns false for self-signed passports'). While it doesn't cover all error paths or explicitly state the return value for valid passports, the behavioral detail provided is meaningful and goes beyond a generic 'verify' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word contributes value. It avoids redundancy with the schema and annotations (which are absent), making it an example of efficient, well-structured prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally clarify return semantics; it only states 'Returns false for self-signed passports,' implying a boolean return but not stating it outright. However, the tool's purpose is simple enough that the verification logic and one key edge case are sufficient for an agent to understand expected behavior. The description is complete for practical use, though a slight mention of 'true' condition would make it perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% structural coverage of the nested passport object, so the baseline is 3. The description adds context about the role of the issuerSignature and the self-signed condition, which slightly enriches parameter meaning, but it does not detail field-by-field semantics beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verify') and a precise resource ('a passport was officially issued by AEOESS'), clearly distinguishing it from sibling verify tools (verify_charter, verify_delegation, etc.). It also explains the verification mechanism (countersignature against AEOESS public key), leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this tool when you need to confirm that a passport was officially issued by AEOESS, particularly validating the issuer's countersignature. It does not explicitly name alternatives or exclusions, but the scope is specific enough that an agent can distinguish it from other verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries the burden of behavioral disclosure. It discloses the return format ({valid: true} or {valid: false} with specific reason codes) and reveals a key behavioral trait ('purely local'), which is valuable. It does not mention potential exceptions, performance, or permission requirements, but for a verification tool the return-value transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding necessary information. It front-loads the verb and resource, then details the return format and the local-only nature. No redundant or filler content, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with two well-documented parameters and no output schema, the description is complete. It explains the return values (including possible reason codes) and the local execution model, covering all essential aspects a user would need to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters ('projection' and 'issuer_public_key'), including descriptions. The tool description adds minimal extra meaning beyond the schema—only clarifying that 'projection' comes from aps_project_attribution, which is also mentioned in the schema. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 a single-axis AttributionProjection under the issuer's Ed25519 public key. It uses a specific verb ('verify'), identifies the resource ('AttributionProjection'), and distinguishes itself by noting 'single-axis' and 'purely local — no other axes required', which differentiates it from sibling APS verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by emphasizing 'single-axis' and 'no other axes required', implying this tool is appropriate for single-axis verifications without requiring additional data. However, it does not explicitly name alternative tools or state when to use them, leaving room for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses the entire pipeline, including verifying signature+hash, checking terms, and creating a signed access receipt (a side effect). However, it does not explicitly mention failure modes (e.g., what happens if verification fails) or whether any persistent state is written beyond the receipt, so it is not fully transparent but is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a clear arrow-delimited pipeline. Every word earns its place, and the high-level flow is front-loaded. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter composite tool with no output schema, the description explains the high-level workflow but omits return value format, error handling (e.g., what happens on signature mismatch), and any postconditions beyond creating a receipt. This is a meaningful gap for a tool called on every page read, though the pipeline itself is well described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents most parameters. The description adds pipeline context that implies roles (html/contentBody for extraction/hash, keys for signing, intendedUsage for terms, sourceUrl for provenance), but it doesn't provide per-parameter semantic detail beyond what the schema gives. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute') and resource ('HTML content') and clearly outlines a multi-step pipeline: extract governance block → verify signature + content hash → check usage terms → create signed access receipt. This distinguishes it from the many sibling tools that perform only individual steps, making its composite purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'This is what an agent calls on every page it reads.' This provides clear contextual guidance and implies that for the full governance loop, this composite tool is the default instead of calling individual sibling tools like verify_governance_block or create_access_receipt separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only behavior ('Show') and the env var effect, which is useful. However, it does not describe the return format, whether it reads from a configuration, or any error conditions. For a low-risk listing tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose and followed by a single, relevant usage note. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple, parameterless tool with no output schema, the description fully addresses what it does and how to influence its behavior. It is complete for the tool's complexity and context, especially when compared to the large set of sibling tools that require more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain any. The schema coverage is 100% (empty properties), and the description adds the meaningful context of the env var, which effectively acts as a parameter. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Show available tool profiles.' It uses a specific verb and resource, and the mention of the APS_PROFILE env var distinguishes it from sibling tools that list tasks or tools for a different scope, like list_tools_for_scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage guideline: setting the APS_PROFILE env var limits exposed tools. It implies when this tool is useful (to see profiles and control tool exposure), though it does not explicitly name alternatives or exclusions. This is sufficient for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It transparently reveals the computation formula (prompt_tokens + completion_tokens × COMPLETION_MULTIPLIER, default 3.0), the normalization, and the output format (canonical ComputeAxisEntry[] with 6-digit decimal strings summing to ~1.0). This is substantial, although it omits error handling, permissions, and potential side effects, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, covering purpose, formula, output, and usage in roughly four sentences. It is front-loaded with the core action and immediately gives the output type and downstream consumer. Every clause contributes substance without redundancy, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description thoughtfully explains the return format and the computation, filling the gap left by no output schema. It also connects to the downstream primitive. While it doesn't cover edge cases, error conditions, or profile details, the provided context is sufficient for typical use, so it scores a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds beyond this by explaining how the parameters are used: 'providers' are per-provider billing records, 'profile' is an optional override, and the formula ties prompt_tokens/completion_tokens to the multiplier. This enriches the semantics beyond the raw schema, meriting a 4 (baseline is 3 for high coverage, and this adds extra value).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: 'Compute the C-axis fractional weight vector from a list of inference billing records'. It specifies a concrete verb ('compute'), a resource ('C-axis fractional weight vector'), and contextual distinction by referencing the sibling primitive 'aps_construct_attribution_primitive' and implicitly contrasting with 'aps_compute_data_axis_weights' (sibling). This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: 'feed directly into aps_construct_attribution_primitive' and lists the input type (inference billing records). It implies the tool is for C-axis weight computation, which differentiates it from siblings like 'aps_compute_data_axis_weights'. However, it lacks explicit 'when not to use' or alternative guidance, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the return format ({valid: true} or {valid: false, reason, detail}), highlights the strongest invariant (S3 conservation) and its security implication. It could mention error handling for malformed records, but the provided details are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the action and scope, then adds the key invariant and return format. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only verification tool, the description is quite complete: it lists the verification criteria (S1-S5), describes the return shape, and explains the optional parameter behavior. The lack of an output schema is partially mitigated by the return format. Minor gaps include not explaining terms like 'residual shape' for unfamiliar agents, but this is acceptable for domain-specific tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 description adds semantics beyond the schema by explaining that passing inputReceipts triggers S5 cross-checking and recomputes input_receipts_hash, and that gateway_public_key is the Ed25519 key for verification. This added context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') plus a specific resource ('a signed SettlementRecord') and scopes it to S1-S5 checks (signature, Merkle roots, conservation, residual shape, optional input-receipts cross-check). This clearly distinguishes it from sibling verify tools like aps_verify_attribution_primitive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (to verify a signed SettlementRecord) and provides guidance on the optional inputReceipts parameter to enable an additional cross-check. It does not explicitly name alternatives or list exclusion conditions, but the context is sufficient for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the ownership requirement, the promoted-statement restriction, and the exact signature payload format (canonicalize({action:'withdraw', statement_id})). It does not mention reversibility or return behavior, but the disclosed constraints are substantial and actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds distinct information. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context for invocation: the action, constraints, and signature requirement. With no output schema, it omits return/error behavior, but the schema handles parameter documentation and the constraints are well-articulated. Moderately complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions, but the description adds meaningful semantics by specifying the canonicalization payload for the author_signature and clarifying the author-ownership requirement for the statement parameter. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'author withdraws their own provisional statement.' It clearly differentiates from siblings like aps_create_provisional and aps_promote_statement by specifying the withdrawal action and the restriction against promoted statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context (author withdrawing own provisional statement) and an explicit exclusion ('Already-promoted statements cannot be withdrawn'). Does not name alternative tools explicitly, but the when-not 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.
Behavior4/5
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 explains the deterministic nature, the canonical JCS + sha256 computation, the required inputs, and the return value or failure reason. It does not explicitly state whether the operation has side effects, but the 'derive' and 'compute' language strongly implies a pure, stateless operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver a high density of relevant information without waste. The most important facts (what it does, determinism, algorithm, return value) are all present, and the description is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does a good job of explaining the return value and failure behavior. It could be more explicit about the policy parameter's role and any preconditions (e.g., that both attests must be generated by mutualAuthBuildCertificate), but overall it is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's parameter descriptions are minimal type names (e.g., 'MutualAuthPolicy', 'MutualAuthAttest'), but the description adds meaning by explaining that agent_attest and is_attest are the two sides' Attests and that the derivation uses canonical JCS + sha256 of chosen_version, cert ids, and nonces. This helps the agent understand what values to provide even though the schema is sparse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Derive') and resource ('shared mutual-auth session record'), and clearly distinguishes this from sibling tools like mutualAuthBuildCertificate and mutualAuthVerifyAttest by focusing on deriving a session from both sides' Attests. It also names the key output (session_id + certificates + expiry bounds), 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the context: it creates a shared session from both sides' attests and emphasizes both parties must compute identical session_id. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient to guide an agent when this tool is appropriate versus other mutual-auth operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 transparently describes the side effect of creating a GitHub issue, the auto-processing delay (~30 seconds), the auth requirement, and the post-registration capability. This is excellent disclosure for an agent, covering side effects, timing, authorization, and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose. Each sentence provides distinct value: registry location, mechanism and timing, auth requirement, and outcome. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the overall process, requirements, and outcome. However, since there is no output schema, it does not specify what the tool returns (e.g., issue URL or status), which might be important for an agent orchestrating next steps. Still, given the moderate complexity and absence of annotations, the description is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter described in the schema. The description adds minimal extra semantics, mostly repeating the token env var option already present in the schema. It does not introduce any parameter-level nuance beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: registering an agent in the PUBLIC Agora registry at aeoess.com. It distinguishes itself from the sibling 'register_agora_agent' by emphasizing the public registry and the specific mechanism (GitHub issue auto-processed by a GitHub Action). The outcome is also mentioned (ability to post signed messages), providing a complete picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: it requires a GITHUB_TOKEN env var or direct token parameter, and explains the async process. It does not explicitly state when NOT to use it or name alternatives, but the emphasis on 'PUBLIC' and the presence of a sibling 'register_agora_agent' imply a distinction. This qualifies as clear context with no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently states the direction of state changes (success increases mu, decreases sigma; failure opposite) and the scaling effect of evidence class. It does not discuss permissions or error cases, but the core behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and immediately followed by the key behavioral details. Every clause earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers purpose, behavior, and a key parameter relationship. It lacks explicit guidance on choosing this tool over sibling reputation tools and omits permission requirements, but given the schema's completeness and the simple nature of the update, it is adequately contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 5 parameters (100% coverage). The description adds useful semantic information by explaining how 'success' affects mu/sigma and how 'evidenceClass' influences magnitude—details not present in the schema. It does not elaborate on scope/principalId, but overall it enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('Update an agent's reputation') and clearly indicates the context and effect ('after a task result'). It also distinguishes itself from sibling tools by naming the internal mu/sigma mechanics and evidence class scaling, which separates it from tools like vouch_reputation or apply_reputation_downgrade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context ('after a task result') and explains the expected effect based on success/failure. However, it does not explicitly mention alternative tools or state when not to use this tool, so it stops short of full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses that the tool no longer executes and returns a deprecation notice. It could add a bit more about the notice's format or that input parameters are ignored, but the core behavioral change is transparently stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the deprecation status, and every clause adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated stub tool with no output schema, the description fully covers what the tool does, why, and what to use instead. It even points to the gateway endpoint via the deprecation notice, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds no parameter-specific meaning beyond noting that the tool is deprecated, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is explicit: the tool is deprecated and now returns a machine-readable deprecation notice instead of running the preflight pipeline. It clearly states the resource (commerce preflight orchestration) and the new behavior, distinguishing it from the actual preflight functionality now living in the gateway.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when not to use this tool ('no longer runs the pipeline locally') and provides concrete alternatives: 'Compose the pure gate predicates from the SDK yourself, or call the gateway.' This is perfect usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explicitly lists all 10 verification checks (signature, version negotiation, nonce match, timestamp freshness, certificate validity, issuer anchor check, binding constraints, downgrade detection, attestation grade policy, capability policy) and states the return behavior (ok:true on success or a failure reason). This exceeds minimal disclosure and gives the agent a strong mental model of the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, check list, and return behavior. Every sentence contributes unique information, with no redundant or filler content. It is front-loaded with the main purpose and the check list provides detailed value in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 5 required) and lack of output schema, the description compensates by explaining the success/failure return and detailing all verification checks. The schema covers parameter semantics, so the description covers the non-schema aspects (return shape and internal checks). There is no missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions for all 7 parameters, so the baseline is 3. The description adds no new parameter-level semantics beyond what the schema provides, though it does link the nonce parameters to the nonce-matching check. This is sufficient but not elevating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the specific resource 'MutualAuthAttest against policy and trust anchors', which distinguishes it from the sibling tool 'mutualAuthVerifyTrustBundle'. It also enumerates the exact scope of checks, leaving no ambiguity about what is verified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to verify a MutualAuthAttest against policy and trust anchors. It does not explicitly mention alternatives or when-not cases, but the context is sufficiently clear given the sibling tools and the detailed check list. A slightly higher score would require explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral details: empty input returns empty array, all-zero raw weights cause an error, output uses 6-digit decimal strings, weights sum to ~1.0, and the exact formula (role × recency_decay × length_weight) normalized per spec BUILD-B.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense: three sentences cover purpose, output, edge cases, formula, spec reference, and SDK naming. Every sentence earns its place and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description gives a complete picture: input types, output format, normalization target, error condition, formula reference, and a downstream consumer. It is sufficient for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described in structured data. The description adds value by explaining the weight formula, the default profile behavior, and that parameter names align with the SDK, which helps an agent understand how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Compute') and clearly identifies the resource ('D-axis fractional weight vector'), input type (AccessReceipt records), and output (DataAxisEntry[]). It also ties the output to a downstream sibling (aps_construct_attribution_primitive), which helps distinguish it from other computation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is strongly implied by stating the input requirements and that the result 'feed[s] directly into aps_construct_attribution_primitive.' It also conveys context like empty/all-zero edge cases, but it does not explicitly state when not to use this tool or mention alternatives for other axes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agent-passport-mcp MCP server](https://glama.ai/mcp/servers/aeoess/agent-passport-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aeoess/agent-passport-mcp)

Score Badge

Copy to your README.md:

[![agent-passport-mcp MCP server](https://glama.ai/mcp/servers/aeoess/agent-passport-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aeoess/agent-passport-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aeoess/agent-passport-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server