viridis-agent-fleet

Server Quality Checklist

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

Latest release: v0.1.12
Disambiguation4/5
Tool names are prefixed by service domain (e.g., offsets__, neurogenesis__), making them clearly distinguishable despite high volume. A few generic names like describe_agent appear across services but are unambiguously scoped by prefix.
Naming Consistency5/5
Every tool follows a consistent service__verb_noun pattern in snake_case. No mixing of conventions, and verbs are appropriately descriptive. Excellent uniformity.
Tool Count2/5
117 tools is excessive for a single MCP server, even if it represents a fleet. Most focused servers have 3-15 tools; this is far beyond that, making it unwieldy for an agent to navigate efficiently.
Completeness3/5
Individual services within the fleet vary in completeness—some (like offsets) have comprehensive CRUD, while others (like arbitration) have only one tool. Overall coverage is broad but uneven, with several services lacking lifecycle operations.
Average 3.3/5 across 94 of 117 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 94 commits in the last 12 weeks
- Last stable release on July 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Self-description' implies read-only introspection but provides no details about side effects, required permissions, or what information is returned. The description is insufficient for an agent to understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but at the expense of informativeness. 'Fleet-standard self-description' is not a clear, well-structured description. It lacks key elements and reads more like a placeholder than a meaningful explanation.
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 no output schema and no parameter guidance, the description should explain what the self-description includes (e.g., capabilities, metadata). It fails to provide enough context for the agent to understand what calling this tool will yield.
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 zero parameters and 100% schema description coverage. The description adds no parameter details, but none are needed. Baseline of 3 is appropriate since schema already fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description only says 'Fleet-standard self-description' which is vague and tautological. It does not clearly state that the tool returns metadata about the arbitration agent, nor does it distinguish from other describe_agent tools for different modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. For example, it does not explain that this is the tool to introspect the arbitration agent, while other arbitration tools handle disputes, cases, or evidence.
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, the description must disclose behavior. It only says 'self-description' without stating what information is returned, side effects, or any constraints. This is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential content. It is under-specified, not concise; every sentence should earn its place, and this one does not.
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 no output schema and no annotations, the description is completely inadequate. It fails to explain what the tool does, making it impossible for an agent to correctly select and invoke it among many similar describe_agent tools.
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?
There are no parameters, so schema coverage is trivially 100%. However, the description should explain what the tool returns or how it works, but it adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Fleet-standard self-description' merely restates the tool name and provides no specific verb or resource. It does not differentiate from many sibling describe_agent tools (e.g., notary__describe_agent, neurogenesis__describe_agent).
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 its many siblings. No context or when-not-to-use instructions are provided.
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?
No annotations provided. Description does not disclose any behavioral traits (e.g., read-only, data returned, side effects). The description completely fails to inform the agent about 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but at the cost of informativeness. The sentence does not earn its place as it provides minimal 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?
No output schema and no description of return values. The tool's purpose and output are left completely undefined, making it unusable for an AI agent without external knowledge.
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?
No parameters defined, so schema coverage is 100%. Baseline of 3 applies. Description does not add any parameter-related meaning, but that is acceptable given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fleet-standard self-description' but is vague. It does not specify what aspects of the agent are described (e.g., trust state, metadata) and fails to distinguish from sibling describe_agent tools in other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other describe_agent tools. Critical missing context given many siblings with similar names.
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, the description should disclose behavioral traits. It does not mention whether the tool is read-only, requires authentication, or any side effects. The description is insufficient for understanding what the tool does.
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 short (one sentence). While concise, it lacks necessary detail. It could be expanded to add value without being verbose.
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 no output schema and no parameters, the description should explain what the 'self-description' entails. It does not provide enough context for an AI agent to understand what the tool returns or how it differs from 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?
The input schema has no parameters, so schema description coverage is trivially 100%. The description adds no parameter information, but none is needed. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fleet-standard self-description' is vague and does not specify what the tool does beyond a generic self-description. It fails to distinguish this tool from other describe_agent tools in the fleet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no indication of when to use this tool versus alternatives, such as other describe_agent tools or other compute-ledger 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, the description should disclose behavioral traits. It does not mention that this is a read-only query, authentication requirements, or any side effects. The prefix about exactly-once settlement is generic and not specific to this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but overly terse; it sacrifices clarity for brevity. The prefix adds module context but does not describe the tool's function. Structure is minimal and unhelpful.
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 no output schema, the description should hint at the response structure. 'Current record' is too vague; it does not specify what fields are returned or if pagination applies. The tool is critically under-described.
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?
The schema has 0% coverage for parameter descriptions, and the tool description does not explain what escrow_id is or how to obtain it, leaving the agent without necessary context for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current record for an escrow' is vague and does not explicitly state that the tool retrieves the status of an escrow. It lacks a verb and fails to distinguish from sibling tools like escrow__list_escrows.
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 escrow__list_escrows or other escrow-related tools. The agent receives no context for decision.
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?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., side effects, permissions, rate limits). The description is too brief to convey behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but at the expense of clarity. It is under-specified and lacks key information, making it not 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 output is not described beyond 'capabilities and input contract'. With no output schema, the description must explain return values, which it does inadequately.
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?
With zero parameters, the schema already fully describes inputs. Baseline is 4. The description adds no additional parameter information, but that is acceptable given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return capabilities and input contract' is vague. It does not clearly state what the tool does. The verb 'return' is present but the resource is ambiguous. Among many describe_agent siblings, this does not distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other describe_agent tools. The description provides no context for 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?
The description provides some behavioral context by noting it is a 'staging preview; non-authoritative until the K3 swap.' However, it is ambiguous whether side effects like binding DIDs and pricing toll are part of this tool's action. No information about safety or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and includes bracketed text that appears to be a general system introduction, not directly relevant to this specific tool. It is not front-loaded with the core action.
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 no annotations, no output schema, and 3 undocumented required parameters, the description is highly incomplete. It does not explain input meaning, expected output, or error conditions, leaving the agent with insufficient information to use the tool 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?
The input schema has 3 required parameters with 0% description coverage. The description does not define or explain 'module_id', 'subject', or 'inputs', adding no semantic value beyond the schema.
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 that the tool certifies a parcel against a theorem and returns a 'Certified by ViridisOS' mark envelope. However, it is mixed with general ViridisOS system description and mentions binding DIDs and pricing toll, which muddles the specific tool purpose. It does not clearly distinguish from the sibling tool viridis_certify.
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 like viridis_certify or viridis_verify_mark. The description does not mention prerequisites, exclusions, or 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 exist, so the description must convey behavioral traits. It implies a read-only operation ('routing recommendation'), but fails to explicitly state that it does not modify state, nor does it mention any side effects, safety concerns, or dependencies.
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 short (two sentences), but the first bracketed sentence is dense and potentially confusing. While concise, it sacrifices clarity and structure.
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 no output schema, no annotations, and 0% schema coverage, the description is severely incomplete. It does not explain what the output looks like, how to interpret 'cognitive steps', or any limitations or edge cases.
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?
The description adds no meaning to the three parameters (agent_id, from_node, limit). Schema coverage is 0%, so the description should compensate, but it does not mention any parameter.
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 returns 'the strongest next cognitive steps from a given node', which clarifies the verb and resource. However, terms like 'cognitive steps' and the intro bracket are vague, and no distinction is made from siblings like route_task.
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 vs. alternatives such as route_task. The description lacks any context about when it is appropriate to call this function.
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 calls itself a 'Free read', implying it is read-only, but does not elaborate on side effects, authorization needs, or performance implications. The abstract physics framing adds little practical 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and cluttered with jargon and brackets. It is not concise or front-loaded; key information is buried in a dense, metaphorical phrase.
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 simple schema (one optional parameter) and no output schema, the description should clearly specify the output structure and scope. It mentions some elements (counts, costs, reasons) but lacks concrete details, leaving the agent guessing about the actual return format and semantics.
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?
The only parameter 'limit' is not mentioned or explained in the description. With 0% schema coverage, the description should compensate by describing what 'limit' controls, but it fails to do so.
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 returns a 'routing decision log' with counts, costs, and reasons, which gives a general sense of purpose. However, the heavy use of jargon ('Landauer-floor physics context', 'Intelligence Bound frame') obscures the exact functionality and output, making it less clear than it could be.
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 'compute-ledger__list_inventories' or other neurogenesis tools. There is no explicit context for when it is appropriate or when not to use it.
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 convey behavioral traits. It only lists returned components but does not mention read-only nature, potential performance impact, response size, or any side effects. 'Full current state' is vague and lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes an extraneous bracketed prefix ('neurogenesis — developmental agents...') that seems like a module header rather than tool-specific info, adding noise. The actual functional description is a single sentence, but the tool would benefit from a more structured, parameter-focused format.
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 absence of output schema and the tool's complexity within a large module, the description fails to explain the meaning of 'genome', 'cognitive graph', 'trust', or the structure of the response. It does not address automation needs like pagination, filtering, or error conditions.
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 coverage is 0%, so the description must add meaning. It does not describe the 'agent_id' parameter at all—no format, constraints, or how to obtain it. The description focuses solely on output, ignoring 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 states the tool returns the 'full current state' including genome, cognitive graph, and summary counts, which clearly indicates what it retrieves. The bracketed prefix is confusing but does not obscure the purpose. It distinguishes from sibling tool 'neurogenesis__describe_agent' by implying a more comprehensive output.
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 'describe_agent' or 'list_agents'. The description does not mention prerequisites, conditions, or preferred scenarios for invoking get_agent.
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 fully disclose behavioral traits. It states the tool fetches a record with rulings, but does not mention whether it is read-only, authorization requirements, or error behavior (e.g., what happens if case_id is invalid). The behavioral disclosure is insufficient.
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 concise (one sentence) but lacks essential details about parameters and behavior. While brevity is good, it comes at the cost of completeness. It is neither overly verbose nor efficiently informative.
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 one required parameter, no output schema, and no annotations, the description does not provide enough context for safe and correct usage. Missing details include parameter semantics, possible return values, and error conditions. It leaves significant gaps for an AI agent.
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 the `case_id` parameter beyond what is in the schema. It does not clarify the expected format, uniqueness, or how to obtain the ID. This leaves the AI without necessary context for parameter usage.
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 'Fetch' and the resource 'full case record, including any ruling.' It distinguishes from sibling tools like `arbitration__list_cases` (listing) and `arbitration__file_case` (creating), so the purpose is specific and 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?
The description provides no explicit guidance on when to use this tool versus alternatives, such as `arbitration__list_cases` for browsing or `arbitration__verify_ruling` for verification. The context is implied but not stated, leaving the AI to infer appropriate usage.
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 mentions output fields but does not confirm read-only behavior, auth requirements, or any side effects. Lacks typical transparency for a status tool.
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 the bracketed prefix seems like metadata and may add noise. It front-loads the key info but could be better 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?
Given no output schema, the description does list the return components (state, budget, check count). However, it lacks specifics like state enum values or budget units, making it barely adequate for a simple status check.
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 coverage is 0%, meaning the schema provides no description for the sole parameter covenant_id. The description adds no explanation of what a covenant_id is or how to obtain it, so it fails to compensate for the schema 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 it returns the current state, consumed/remaining budget, and check count, indicating a status/read tool. It distinguishes from sibling mutation tools like grant and revoke, though it does not explicitly label itself as read-only.
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 list_covenants or check_act. The description only states what it returns, without context 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states it is 'FREE' and gives output fields. It does not mention side effects, authentication, rate limits, or any operational traits, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with a marketing tagline ('[green-router...]', 'honest books, GR8') that adds little operational value. While it has some structure, it is not concise and includes unnecessary promotional language.
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 lack of output schema, annotations, and parameter descriptions, the description should provide a complete picture but only gives vague output fields. It does not clarify the return format, whether it lists individual certificates or summarized data, or any other details needed for correct 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?
The single parameter `limit` has no description in the schema (0% coverage) and is not explained in the description. The agent receives no semantic information about what the parameter controls or its impact.
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 identifies the tool as returning the certificate ledger with counts, total grams retired, and total clearinghouse cost, making the purpose clear. However, the name suggests listing individual certificates, while the description implies aggregated totals, causing slight ambiguity.
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 sibling tools like `green-router__quote_footprint` or `green-router__verify_green_certificate`. The description lacks any explicit usage context 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 must disclose behavioral traits. It only says 'Remove', without mentioning irreversibility, permissions, or side effects. This is insufficient for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a lengthy, irrelevant prefix that wastes space. The functional part is minimal, but the wasted words reduce 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?
For a deletion tool with one parameter and no output schema, the description should specify what constitutes a valid agent_id and the effect of deletion. It does neither, leaving the agent underinformed.
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 coverage is 0% and the description does not explain the sole parameter ('agent_id'). The agent lacks any hint on how to obtain or format this ID, making it hard for an AI to use correctly.
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 ('Remove') and the resource ('developmental agent'), which distinguishes it from sibling tools like 'describe_agent' or 'export_state'. However, the confusing prefix adds noise and detracts from 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 (e.g., deactivating vs. deleting). Given many sibling tools, explicit usage context is missing.
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. It notes the ledger is 'append-only' and events are 'returned verbatim', but fails to mention that the tool is read-only (non-destructive), whether authentication is needed, or any limitations like pagination or performance. The safety profile is partially implied 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the core sentence is concise, but it includes an unnecessary prefix ('[neurogenesis — developmental agents...]') that adds domain context without aiding tool selection. The main point is delivered, but some words could be trimmed for better front-loading.
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 no output schema and no annotations, the description should compensate by explaining return format, event ordering, or error conditions. It mentions 'NG3 — returned verbatim' but lacks details on data structure, pagination, or whether the agent must exist. The tool is simple but still leaves significant gaps for an AI agent.
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?
The input schema has two parameters (agent_id required, limit optional with default 100) but the description does not mention either parameter or their semantics. Zero schema description coverage forces the description to compensate, but it adds no parameter information, leaving the agent guessing about required input and how to control output size.
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 it returns 'the append-only developmental ledger' containing 'every growth, pruning, and evaluation event with reasons', effectively communicating the tool's purpose as a read-only accessor for ledger events. It is distinguishable from sibling tools like neurogenesis__describe_agent or neurogenesis__export_state which serve different functions.
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 lacks context about scenarios (e.g., auditing, debugging) and does not mention prerequisites or when not to use it. Sibling tools exist but no comparative guidance is 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 provided, so description must disclose behavior. It describes calculation logic but doesn't state if it's read-only, mutating state, or requires authorization. Side effects and data sources are unclear.
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?
Description is very short but includes a redundant prefix '[offsets — verified-credit carbon offset clearinghouse]'. It uses concise but jargon-dense language.
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?
Missing output schema and low schema coverage leave significant gaps. Description only mentions a flag 'carbon_accountable' without specifying the full output format or return behavior.
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 coverage is 0%, and description does not explain the meaning of 'buyer' or 'emitted_g' (e.g., unit, format). Agent cannot determine what values to provide without domain knowledge.
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 states the tool computes buyer's carbon position as emitted minus retired, and mentions a carbon_accountable flag. It distinguishes from siblings like offsets__buy_offset, offsets__book, etc., but uses jargon that may require domain knowledge.
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 siblings. It doesn't state prerequisites or scenarios where it's applicable, nor does it mention 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, the description carries full burden. It mentions recomputing and verifying but does not disclose whether this is a read-only operation, required permissions, side effects on failure, or any rate limits. Behavioral context is minimal.
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, but it includes a bracketed prefix that appears to be a category tag rather than part of the description. While concise, this prefix may confuse. The description could be clearer without it.
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 of a generic object parameter and no output schema, the description fails to cover return values, error scenarios, or required input structure. Significant gaps remain for the 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema defines the artifact parameter as a generic object with no properties. The description provides no guidance on what fields the artifact object should contain, leaving the agent unable to construct valid input.
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: recompute artifact record hash and verify against DAG ledger. The verb-resource pair is specific. However, it does not explicitly differentiate from sibling tools like provenance__verify_certificate, leaving some ambiguity.
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 vs alternatives. No prerequisites, exclusions, or examples provided. The description implies verification but does not specify when verification 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 disclose behavioral traits. It only says 'Monitor...', implying a read operation, but lacks details on authentication, rate limits, output format, or what constitutes a 'change'. The trailing window is mentioned but not defined in terms of update frequency or data retention.
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 only one sentence, but it includes a product prefix '[regulatory-radar — ...]' that is not needed for tool functionality and wastes space. The core information is concise, but the structure could be improved by moving the prefix elsewhere.
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 no output schema, no annotations, and no parameter descriptions, the description is incomplete. It does not explain return values, pagination, or how results are formatted. For a monitoring tool, this is insufficient for correct agent 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 coverage is 0%, and the description does not explain any of the three parameters. 'jurisdiction' is required but no format/example given; 'since_days' and 'payment_ref' are defaulted but their purpose is unclear. The description adds zero meaning 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 tool monitors recent regulatory changes in a jurisdiction over a trailing window. The verb 'Monitor' and resource 'regulatory changes' are specific, but it does not explicitly distinguish from siblings like assess_compliance or scan_regulations, which slightly reduces 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 is provided on when to use this tool vs alternatives, such as assess_compliance or scan_regulations. There are no exclusions, prerequisites, or usage context, 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 carries full burden for behavioral disclosure. It only describes the output (call/error counts and fees) but does not state that this is a read-only operation, whether multiple calls affect state, or any access requirements. The tool likely is idempotent, but the description does not confirm.
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 core description is concise: 'Call counts, error counts, and accrued fees for one service.' However, the prefix in brackets is unnecessary and wastes space, reducing conciseness. The description is not structured (e.g., no bullet points) but is short enough to be scanned 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 simplicity (one parameter, no output schema), the description is incomplete. It explains the output but omits how to use the service_id parameter and any return format. An agent would need to infer from the tool name or sibling tools, which is suboptimal.
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?
The input schema has one required parameter 'service_id' with zero description coverage. The tool description does not mention 'service_id' at all, so it adds no meaning beyond the schema. The agent has no clue what value to provide or how to obtain it.
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 returns 'Call counts, error counts, and accrued fees for one service,' which is a specific verb and resource. It distinguishes from sibling tools like verified__list_services (which lists services) and verified__get_receipt (which gets a receipt). However, the prefix '[verified — tamper-evident delivery receipts ...]' adds branding noise that could distract from 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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as verified__list_services or verified__get_receipt. There is no mention of prerequisites (e.g., needing a service_id from list_services) or when not to use it.
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 notes 'Staging preview; non-authoritative until the K3 swap,' which is a behavioral caveat. However, it lacks details on side effects (e.g., state changes, persistence), required permissions, or trust prerequisites. Since no annotations are provided, the description carries full burden and only partially meets it.
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 contains a verbose bracketed paragraph that seems module-level rather than tool-level, mixing multiple actions. The core sentence is concise but the extra text adds noise. It could be streamlined to focus on the tool's specific action.
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 simplicity (1 param, no output schema, no annotations), the description should fully explain what the tool does, what 'event' is, and the resulting envelope. It provides high-level context about ViridisOS but omits critical details about the parameter and output, leaving an AI agent underinformed.
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?
The only parameter 'event' is a required string with zero schema description coverage. The description does not mention or explain this parameter, leaving its meaning and expected format completely unspecified. The description should compensate for the schema gap but fails to do so.
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 'Issue a mark-stamped agent-attestation envelope,' which is a specific verb+resource. However, the preceding bracketed text describes broader ViridisOS capabilities (certify parcel, bind DID, price toll) that overlap with sibling tools, creating confusion. The tool's purpose is distinguishable but not clearly differentiated from siblings like viridis_certify_envelope.
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 bracketed text lists related capabilities but does not direct the user to other tools for those actions. The description does not provide '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It notes the staging/non-authoritative status and a blocked error, but fails to mention side effects, authentication needs, or data persistence. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains verbose jargon (e.g., 'gate-passed canon theorem', 'bind did:viridis identities', 'K3 swap') that obscures the core functionality. The second sentence is clear, but the first part is overly complex and less 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 three required parameters and no output schema, the description should cover parameter details and return structure. It mentions the output is a certificate but provides no format or content specification. Incomplete for effective use.
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%. The description does not explain the purpose or format of any of the three required parameters (inputs, subject, module_id). It adds no semantic value 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 tool certifies a subject (parcel/portfolio) using a module to produce a certificate. It uses specific verbs and resources, but does not explicitly differentiate from sibling tools like viridis_certify_envelope or viridis_verify_mark.
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. It mentions an error condition (module's theorem not gate-passed) but lacks explicit when-to-use or not-to-use 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?
With no annotations, the description should disclose behavioral traits like side effects, authentication needs, or response format. It only mentions verifying against a 'shared trust root', implying a read operation, but fails to confirm whether it modifies state or has rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a lengthy, unrelated preamble about ViridisOS system features (certification, binding, pricing) that adds noise. The core verification purpose is only a single sentence, making it hard 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 no output schema and no parameter descriptions, the description omits critical details like return value, error cases, and contrast with similar tools (e.g., viridis_certify_envelope). This leaves the tool under-specified 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%, so the description must explain parameters. The 'envelope' parameter is mentioned in the tool name but not described (e.g., format, content). The optional 'profile' parameter is completely ignored, leaving the agent guessing its purpose.
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 'Verify' and the resource 'Certified by ViridisOS envelope', which distinguishes it from sibling tools like viridis_certify. However, it lacks specificity about what verification entails (e.g., cryptographic signature check, status 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 like viridis_certify_envelope or other verification tools. The description does not indicate prerequisites or typical use cases.
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 provided, and description does not disclose behavioral traits such as side effects, permissions, or whether it is read-only. The term 'self-description' implies no side effects, but this is not explicit.
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?
Very concise (one sentence) but lacks structure and informative content. Every word earns its place, but the brevity sacrifices 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?
Given no output schema and no annotations, the description is insufficiently complete. It does not specify what fields or behaviors the agent description contains, leaving the agent uninformed.
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?
No parameters exist, so schema coverage is 100%. Baseline is 3, and description adds no extra semantic value for parameters.
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?
Description indicates it's a self-description for the metering agent, but is cryptic ('Fleet-standard self-description') and does not clearly state what information is returned. Purpose is somewhat inferable from the tool name and 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 guidance on when to use this tool versus other describe_agent siblings. Does not distinguish between similar tools or provide context for appropriate usage.
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 only lists return fields but does not disclose if the operation is read-only, requires any authentication, or has side effects. The description fails to clarify behavioral aspects.
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 but starts with an unusual bracketed prefix that reads as metadata rather than a clear instruction. While it is succinct, the prefix may confuse agents expecting a standard description.
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 no output schema and no parameters, the description should explain what a material pack is and how the tool identifies it (e.g., implicit context). It fails to address these gaps, leaving the agent unsure of what input or output to expect.
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 no parameters (100% coverage), so the description does not need to add parameter details. The baseline of 3 applies, and the description offers no extra semantic value for parameters.
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 returns a material pack with detailed contents (factors, densities, etc.). However, it is unclear whether this retrieves a specific pack or a default, since no parameters are provided. There is no differentiation from the sibling 'list_material_pack' other than the verb, leaving ambiguity.
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 'list_material_pack' or 'get_assembly'. No context about prerequisites or typical use cases 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?
No annotations are provided, so the description must fully disclose behavior. It does not mention what the response looks like, whether results are paginated, if there is a limit, or if the tool is read-only. For a list operation, such details are important for an agent to handle the output correctly.
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, which is concise. However, it includes a bracketed prefix that seems to be metadata ('[compute-ledger — compute-is-carbon energy/carbon ledger]') which adds noise but does not significantly degrade conciseness. The core statement is front-loaded.
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 domain (carbon ledger) and the complexity of the concept 'GHG inventory chain', the description is minimal. It does not define key terms, mention expected output, or explain how this tool relates to other inventory tools. An AI agent would likely need more context to use 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?
There is one required parameter, 'agent_id', with 0% schema description coverage. The description does not explain what the agent_id represents, how to obtain it, or any constraints (e.g., format, validity). The schema provides only a title; no additional meaning is conveyed.
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 specifies the action ('List') and the resource ('separate GHG inventory chain') for an agent. However, the phrase 'separate GHG inventory chain' is somewhat vague, and the tool's purpose might not be immediately understood by someone unfamiliar with the domain. It does differentiate from siblings like 'ghg-ledger__calculate_inventory' which computes a new inventory.
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 (e.g., when to list vs. calculate an inventory). There are no instructions on prerequisites, such as whether an agent must exist or have prior inventories. The description lacks any 'when-to-use' or 'when-not-to-use' 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?
With no annotations, the description must fully disclose behavioral traits. It states the tool is read-only (recompute and report) but omits details like whether it requires on-chain access, rate limits, or what 'intact' means in the context of ERC-8004 attestations.
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 one sentence (plus a bracket prefix). It is short but could be clearer by removing the prefix and integrating domain context more naturally.
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 involves ERC-8004 on-chain identity and has no output schema. The description lacks details on payload structure, return value format, and verification semantics, making it insufficient for correct invocation without external knowledge.
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?
The only parameter is `payload` (object), described only as 'payload' with no added meaning. Schema coverage is 0%, and the description does not explain required fields, structure, or how the hash is computed from it.
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 specifies the action ('recompute content hash' and 'report intactness') and identifies the domain (ERC-8004 identity). However, it does not differentiate this tool from sibling verify_attestation tools (e.g., trust__verify_attestation), which share the same verb and output concept.
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 other verification tools. There is no mention of prerequisites, input constraints, or scenarios where 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions creating a meter and returning a meter_id, but omits side effects (e.g., idempotency, duplicate handling), permissions, or if the meter is immediately active. For a creation tool, this is insufficient.
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 relatively concise at two sentences, but uses a bracketed header that may confuse. It is front-loaded with domain context. Could be more structured but acceptable.
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, so description should explain return value (done: meter_id). However, it lacks error conditions, edge cases, or context about provider/consumer relationships. Incomplete for a tool with six parameters and no schema descriptions.
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 has 0% description coverage, so description must explain parameters. It only explains 'unit' and 'price_minor_per_unit', leaving provider, consumer, currency, and sla_target unexplained. Two out of six parameters covered is inadequate.
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 usage meter between provider and consumer, with specific verb 'create' and resource 'usage meter'. The domain is indicated via bracketed prefix. However, it does not differentiate from other create tools in sibling list, though the unique resource type helps.
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, such as prerequisites like needing provider/consumer agents or that a meter must exist before recording usage. The description only states what it does, not when it 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?
No annotations are provided, so the description carries full burden. It states 'generate' implying a creation action but does not disclose side effects, idempotency, required workspace existence, or any constraints. The description is insufficient for an agent to understand 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 description is a single sentence, which is concise but lacks structure. It could be organized into brief sections for purpose, parameters, and behavior. While it is short, it sacrifices completeness 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 tool complexity (8 parameters, nested objects, no output schema, no annotations), the description is far from complete. It does not explain the return value, the meaning of 'contract', or the role of optional parameters. The agent would need additional context 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 0%, meaning the description must compensate by explaining parameter meanings. The description only mentions 'parametric CAD design' and 'dimensions' but does not clarify any of the 8 parameters such as 'features', 'design_intent', or 'output_formats'. This fails to add value beyond the schema's property 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 verb 'Generate' and the resource 'parametric CAD design contract in a ProtoGen workspace.' It distinguishes from sibling tools like protogen__export_cad_design and protogen__create_cad_workspace. However, the term 'parametric CAD design contract' is ambiguous and could be more specific.
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 vs. alternatives, e.g., when to use protogen__export_cad_design instead. No prerequisites or context signals 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 provided, and the description does not disclose behavioral traits such as being read-only, side effects, or authentication needs. The agent cannot infer safety or idempotency.
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 and a tagline, making it very concise. However, it could be slightly clearer without adding 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?
For a tool with no parameters and no output schema, the description is minimal. It fails to specify the format or scope of the returned information, leaving the agent uncertain about what to expect.
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?
Input schema has zero parameters, so schema coverage is 100%. The description adds some meaning by mentioning the return content but does not elaborate on the structure of 'capabilities and input contract'. Baseline 4 is reduced due to lack of detail.
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 'return SmartScale capabilities and input contract', which hints at the purpose but is cryptic. The bracketed tagline adds context but doesn't clarify the action. It could be more direct 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 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 neurogenesis__describe_agent or notary__describe_agent. The agent has no basis to choose this over 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?
No annotations are provided, so the description carries full burden. It only states the fetch action but does not disclose behavior on missing id, error handling, authentication needs, or output format. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but clear. The prefix in brackets provides context but may be extraneous. It is concise but at the cost of missing useful details.
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 the tool's simplicity, the description lacks information about the return value or error states. Since there is no output schema, the description should have filled that gap but did not.
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 0%, and the description adds no meaning to the 'receipt_id' parameter beyond its name. It does not explain how to obtain a valid receipt_id or any constraints like format or length.
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 'Fetch' and the resource 'a single delivery receipt by id'. The prefix adds context about tamper-evident receipts. However, it does not explicitly differentiate from sibling tools like verified__verify_receipts.
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 such as verified__verify_receipts or other tools. The description does not mention prerequisites or when not to use it.
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 that the tool is a 'Staging preview; non-authoritative until the K3 swap,' which indicates a behavioral trait (non-production). However, it does not discuss side effects, authentication requirements, or what 'margin' and 'pass-through card cost' entail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a lengthy, generic ViridisOS introduction that is not tool-specific. The actual tool purpose is stated in the last sentence, making it not front-loaded. The extraneous text could be moved to a parent tool or removed.
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 two string parameters and no output schema, the description should clearly define the parameters and expected output. It fails to do so, leaving the user guessing what 'payee_tier' and 'amount_minor' represent and what the return value is.
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 does not explain the parameters 'payee_tier' and 'amount_minor'. The description mentions computing 'margin' and 'card cost' but does not map these to the parameters. Without this, the schema alone provides inadequate meaning.
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 includes a clear statement 'Compute the unified Viridis protocol margin (the take) + pass-through card cost for a settlement.' This specifies the action (compute) and the resource (toll/margin + card cost). However, the preceding block of generic ViridisOS text adds confusion and does not differentiate from sibling tools like viridisos__viridis_certify or viridisos__viridis_list_modules.
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 when not to use it, prerequisites, or context. Sibling tools exist for certification, binding, and listing, but no differentiation 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 provided, the description carries the full burden of disclosing behavioral traits. It does not specify whether the operation is read-only or has side effects, what authentication is needed, or rate limits. The minimal description leaves an agent guessing about safety and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the tool's purpose. The namespace prefix at the start is somewhat disruptive but not overly verbose. There is no wasted text, and the core function is front-loaded.
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 verification tool, the description is incomplete. It does not specify the output (e.g., boolean, hash, status), error conditions, or what constitutes a successful verification. Given no output schema, the description should provide this 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 has 0% description coverage, requiring the tool description to explain the agent_id parameter. The description only mentions 'agent's ledger', implicitly linking to the parameter, but does not explicitly state that agent_id identifies the agent whose ledger to verify. This is insufficient for an agent to confidently use the parameter.
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 (Verify) and the resource (tamper-evident hash chain of an agent's ledger). The namespace prefix adds minor noise but is acceptable. It distinguishes from siblings like verify_attestation and verify_inventory_chain by specifying the ledger's hash chain. Clarity is high but not perfect due to the leading prefix.
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 verify_attestation or verify_inventory_chain. The description only states the function, offering no context about prerequisites, exclusions, or when to avoid using it.
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 implies a read-only verification but does not clarify if the operation is destructive, what the return value is, or any authentication or rate limit considerations. The phrase 'tamper-evident' hints at cryptographic verification but lacks specifics.
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 brief, consisting of one sentence with a prefix. It is front-loaded with the verb and resource. While concise, it could include more detail without detracting from 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?
Given no output schema and only one parameter, the description is insufficient. It does not explain what the audit chain is, what constitutes a successful verification, or the format of the result. The agent lacks information about the tool's output or any preconditions.
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 mention the sole parameter 'covenant_id'. With 0% schema description coverage, the description should add meaning, but it fails to explain what covenant_id refers to or how to obtain it. The parameter name is self-explanatory, but the description provides no additional context.
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 specifies the verb 'Verify' and the resource 'tamper-evident audit chain of allowed/denied acts'. This provides a clear purpose and distinguishes it from sibling tools like covenant__covenant_status or covenant__check_act, which address different aspects of covenants.
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 mention prerequisites, when not to use it, or how it compares to other covenant tools such as covenant__covenant_status or covenant__list_covenants.
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 provided. Description mentions recomputing and comparing but does not disclose side effects, permissions, or rate limits. Incomplete for a no-annotation tool.
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 relatively concise but includes promotional text ('FREE forever (GR5):') that is unnecessary and slightly distracts from the core action.
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?
Lacks details on the tool's output or return format; only mentions surfacing a purchase_id. Missing information about success/error indicators or full response, making it incomplete for a verification tool with no output schema.
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?
The single parameter certificate_id has no schema description (0% coverage) and the description does not explain its format or origin, adding no 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 clearly states the tool recompares a certificate's footprint against certified numbers and surfaces a purchase_id, differentiating it from sibling tools like green-router__list_green_certificates and offsets__verify_certificate.
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 when-to-use guidance or differentiation from the many verification sibling tools (e.g., provenance__verify_certificate, offsets__verify_retirement). Only implies a follow-up step to verify retirement.
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 burden. It mentions 'exactly-once' and 'immutable', which hint at idempotency and finality, but lacks details on reversibility, permissions, rate limits, or side effects on events. The description is too brief to provide adequate 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 extremely concise, consisting of two sentences and a prefix. Every word adds value, and it is front-loaded with the tool's purpose. No unnecessary information.
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 that performs a critical action (closing a period, freezing events, creating an invoice), the description lacks information about return values, error conditions, prerequisites, or what happens to existing events. The complexity warrants more detail, especially without an output schema.
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 does not explain the meter_id parameter. No additional meaning is provided beyond the schema's type and name. The description fails to compensate for the lack of parameter documentation.
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 that the tool freezes open events into an immutable invoice for settlement, using specific verbs like 'Freeze' and 'immutable invoice'. It implies a finalization action within the metering suite but does not explicitly differentiate from sibling tools like metering__usage_summary or metering__list_events.
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 closing a period, but there is no mention of prerequisites, when not to use it, or comparisons to other metering 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?
The description only states the action (verify a chain) without any details on side effects, permissions required, rate limits, or what constitutes a valid chain. No annotations are present, so the description carries full responsibility for behavioral disclosure, and it falls short.
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 short, with no superfluous information. The bracket prefix is slightly unnecessary but does not harm clarity. Every word serves a 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 the simple input schema (one parameter) and no output schema, the description should explain what the verification entails, possible outcomes, or response format. It lacks this context, making it incomplete for an agent 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 only parameter, meter_id, is implicitly referenced in the description ('for a meter'), but no additional details are given about its format, source, or constraints. With 0% schema description coverage, the description should compensate but does not.
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 verifies a tamper-evident event hash chain for a meter, specifying a distinct resource within the metering namespace. It does not explicitly differentiate from the sibling compute-ledger__verify_chain, but the namespace and context provide sufficient 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 guidance on when to use this tool versus alternatives (e.g., compute-ledger__verify_chain, metering__list_events). There is no mention of prerequisites, such as requiring a meter ID that must be obtained from another tool.
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?
No annotations are provided, and the description lacks any behavioral details (e.g., read-only, safe, response format). It relies entirely on the minimal 'self-description' phrasing.
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?
Extremely concise (one sentence), but under-specified. The bracketed domain prefix adds context, but the description could be more structured with bullet points for 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?
Given no output schema and no annotations, the description should explain what 'capabilities, inputs, outputs' means in practice. Its brevity leaves ambiguity about what the agent will return.
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 has no parameters (100% coverage), so the description correctly implies no inputs are needed. The tool's simplicity is effectively communicated.
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 'self-description: capabilities, inputs, outputs' which clearly identifies the tool's purpose as providing information about the agent. However, it does not distinguish from other describe_agent tools in the sibling list.
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 vs alternatives like other describe_agent tools or narrative-engine-specific tools. User must infer context from the bracketed prefix.
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 exist, so the description must carry the full burden. It states a read operation but does not disclose whether it requires authentication, has side effects, or what 'capabilities' entail. Minimal behavioral information.
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 but opens with a dense, cryptic prefix ('[neurogenesis — developmental agents...]') that may confuse agents. The core instruction 'Return capabilities and input contract' is clear but could be more direct.
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 no output schema and no parameters, the description must fully explain the tool's behavior. It fails to define 'capabilities' or 'input contract,' leaving significant ambiguity about what the agent will receive.
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 schema coverage is 100%. The description adds no parameter-level detail, but since there are no parameters, the baseline of 4 is appropriate.
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 returns 'capabilities and input contract,' which indicates a read operation. However, it does not specify which agent it describes (e.g., current or specific). The cryptic prefix adds noise without clarifying the tool's exact role.
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 the many sibling `describe_agent` tools in other namespaces (e.g., notary, offsets). It lacks context about the agent being described or prerequisites.
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 fully disclose behavioral traits. It mentions portability and recreation, but does not address side effects (e.g., read-only nature), safety, permissions, output format, or constraints. This leaves gaps for an agent to infer behavior correctly.
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 but contains a verbose parenthetical about the neurogenesis system that adds little tool-specific value. It could be more concise by directly stating the action and counterpart without the system context.
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 simple tool with one parameter and no output schema, the description covers the basic purpose but lacks parameter documentation and behavioral details. It is not fully complete; an agent would need additional context to use it confidently.
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?
The sole parameter agent_id receives no description in the description or schema (0% coverage). The description adds no meaning beyond the schema, leaving the agent to guess its format or semantics. This is a significant gap for a required parameter.
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 exports a 'portable state document for an agent' and explicitly links to import_state as the counterpart, clearly identifying the action and resources involved. It distinguishes from siblings by focusing on state export vs. import or other operations.
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 mentioning import_state and self-hosted environments, but lacks explicit guidance on when to use this tool over alternatives like describe_agent or delete_agent. The context is implied rather than clearly 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, and the description only mentions listing and filtering. It does not disclose behavioral traits such as read-only nature, pagination, rate limits, or any side effects. For an unannotated tool, this is insufficient.
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, which is concise, but the prefix '[provenance — genesis certificates, lineage, recalls]' adds noise and is not fully relevant. It is front-loaded but wastes space.
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 single optional parameter and no output schema, the description is adequate for a simple list operation. However, it lacks any information about return format or pagination, making it incomplete for a tool that might return multiple artifacts.
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%, so the description must compensate. It mentions 'optionally filtered by producer agent' but provides no details on parameter format, allowed values, or behavior when omitted. Minimal added value over 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 tool lists artifacts with optional filtering by producer agent, which is a specific verb+resource. However, it does not explicitly differentiate from sibling provenance tools like get_artifact or lineage, so it lacks 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?
No guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without usage direction.
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 burden. It states the return format (compliance level, percentage, gaps, remediation priorities) but does not disclose side effects (e.g., whether it creates records), authentication needs, rate limits, or cost implications. The 'payment_ref' parameter hints at potentially transactional behavior, but this is not addressed.
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 but includes an unnecessary bracketed prefix 'regulatory-radar — CSRD/TNFD compliance-as-a-service' that could be integrated more naturally. The second sentence lists return items efficiently, but the overall structure could be more streamlined.
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 5 parameters and no output schema, the description only partially clarifies return values. Missing context includes which regulations are applied, how 'company_name' is resolved, and the role of 'payment_ref' (suggests payment requirement). The tool's complexity demands more detail for adequate agent understanding.
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 does not explain any parameter. Required parameters (company_name, sector, jurisdiction) and optional ones (disclosures, payment_ref) are listed in the schema but lack semantic context such as format, allowed values, or usage examples.
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 assesses a company's compliance posture against applicable regulations, with a specific verb ('assess') and resource ('compliance'). It distinguishes itself from sibling tools like `regulatory-radar__monitor_changes` and `regulatory-radar__scan_regulations` by focusing on assessment rather than monitoring or scanning.
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 `scan_regulations` or `monitor_changes`. The description does not mention prerequisites, limitations, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It mentions output masking (account key masked) but does not disclose whether the operation is read-only, required permissions, or any side effects. The verb 'Return' implies read access but is not 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 efficient with two sentences, but the first sentence includes a bracketed domain label that may be considered clutter. Overall, it is front-loaded and reasonably 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?
For a tool returning complex data (subscription lifecycle, quota), the description is vague. No output schema exists, and the description does not clarify what fields or structure to expect, leaving agents with incomplete understanding.
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%. The description does not elaborate on the sole parameter 'account_id' beyond its existence, leaving agents without guidance on format, source, or constraints.
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 returns subscription lifecycle and current-period quota for a bearer-owned subscription. While the name is clear, the description includes a domain header that might be extraneous but does not hinder understanding.
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 subscriptions__mrr_summary or subscriptions__usage_summary. There are no explicit usage 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?
With no annotations provided, the description carries the full burden. It says 'Return' which suggests read-only, but does not explicitly confirm idempotency, safety, or any behavioral traits like permissions or data freshness. For a usage summary tool, more transparency is needed.
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 fits the purpose. The bracketed prefix front-loads context. While it is somewhat dense, it avoids unnecessary words and is efficiently 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?
Given the lack of output schema, the tool's complexity (included/overage usage, periods, lineage, totals), and detailed sibling names, the description is insufficient. It does not explain return value structure, pagination, date range, or how to interpret results, leaving an agent underinformed.
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 single parameter account_id is not explained in the description. The phrase 'bearer-owned' hints that the account is tied to the bearer, but it does not clarify what identifier is expected (e.g., subscription ID, customer ID). With 0% schema coverage, the description should compensate but fails to provide sufficient meaning.
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 it returns usage summary data (included and overage usage) with lineage and conservation totals, clearly identifying the tool's purpose. The context prefix [subscriptions — B2B monthly seats, entitlement quota, overage, and MRR] helps distinguish it from sibling tools like mrr_summary. However, jargon like 'bearer-owned' and 'exact catalog lineage' may obscure meaning.
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 subscriptions__mrr_summary or subscriptions__get_plan. The description implies it is for usage summaries but does not provide context 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?
With no annotations, the description carries full burden. It only states what is returned, not behavioral traits like read-only nature, authentication needs, or side effects. Minimal 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?
Extremely concise single sentence. No wasted words, but could benefit from structuring to separate domain from action. Still 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?
Given the domain (tax credit scenarios) and no output schema, the description lacks detail on what 'bundled rules' and 'metadata' entail. Incomplete for an unfamiliar agent.
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 single parameter 'credit' has no enum or description in schema. The description adds only 'for one credit', which does not clarify acceptable values (e.g., '45Q' vs an ID). Little added meaning.
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 returns bundled rules and metadata for one credit, and the domain is specified in the prefix. However, it does not explicitly distinguish from sibling 'list_rule_packs', which likely returns all packs, so some ambiguity remains.
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 list_rule_packs or calculate_tax_credit. The description only mentions 'for one credit', but does not specify prerequisites or exclusion criteria.
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 must stand alone. It mentions that it is a 'staging preview; non-authoritative until the K3 swap', which provides some context. However, it does not disclose whether the operation is idempotent, whether it has side effects, or what permissions are required.
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 front-loaded with a generic system preamble that is not specific to this tool, taking up space. The key action is in the second sentence. It could be more concise, but the structure is logical.
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 no output schema and no parameter descriptions, the description lacks critical details: what the return value looks like, any prerequisites, and how to properly use the parameters. The staging warning is useful, but overall the tool is insufficiently documented for correct 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 coverage is 0% and the description does not explain the parameters 'agent_id' or 'pubkey'. It adds no meaning beyond the parameter names, leaving agents without guidance on valid values or formats.
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 'derives the canonical did:viridis identity' for an agent, which is clear and specific. However, the initial bracketed text includes other capabilities of the ViridisOS system that are not directly relevant to this tool, slightly diluting focus.
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. Sibling tools like viridisos__viridis_agent_attestation or other bind-related tools are not mentioned, and there is no 'when not to use' advice.
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 burden but only says 'list all entries' without details on pagination, ordering, authentication, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a bracketed prefix that adds minor context but wastes no words; however, it is under-specified for a helpful tool definition.
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 no output schema and no annotations, the description is extremely incomplete, omitting return format, pagination, and other critical behavioral details.
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% coverage for agent_id, and the description does not explain the parameter's meaning or usage, merely mentioning 'for an agent.'
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 (List) and resource (ledger entries for an agent), distinguishing it from sibling tools like compute-ledger__record_work or compute-ledger__list_inventories.
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; lacks context on prerequisites or 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?
The description implies a read-only validation operation but does not specify what the validation entails (e.g., return boolean, throw error), authentication needs, or side effects. With no annotations, more detail is needed.
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 one clear sentence plus a brief prefix. It is concise and front-loaded, though the prefix might be slightly redundant if namespaces are standard. No wasted words.
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 lack of output schema, the description should explain the return result or success/failure indicators. It does not provide enough context for an agent to fully understand the tool's behavior or output.
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?
The only parameter, escrow_id, is minimally described in the schema. The description adds no extra meaning beyond 'for an escrow.' With 0% schema description coverage, the tool should clarify parameter semantics but fails to do so.
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 ('Validate') and the resource ('tamper-evident audit hash chain for an escrow'), which is distinct from sibling escrow tools like fund, release, refund, and status. The prefix also provides namespace 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 on when or when not to use this tool. It does not mention prerequisites, scenarios, or compare with alternatives such as escrow_status or other audit verification 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 full burden for behavioral disclosure. It only states the action without explaining side effects, required permissions, or failure modes. The term 'recreate' implies creation but no details on safety or audit implications.
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-loading the purpose. However, the bracketed prefix is extraneous and not directly helpful for tool invocation.
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 no output schema and minimal description, the tool lacks sufficient context for an agent to understand input requirements, success criteria, or error handling. It is too sparse to be fully complete.
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%, but the description adds no meaning to the 'state' parameter. It only mentions 'from an export_state document' without specifying format, structure, or constraints of the state object.
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 and resource: 'Recreate an agent from an export_state document.' It is specific and distinguishes this import tool from its sibling export_state tool.
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 or how it compares to alternatives. It does not mention prerequisites, typical use cases, or when not to use it.
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 bears full responsibility for disclosing behavior. It states only that a workspace is created, but does not mention any side effects, authorization needs, potential costs (despite a payment_ref parameter), or what happens to existing workspaces.
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 fluff, and the bracketed prefix gives domain context. However, it could be restructured to front-load key information more effectively, though it remains 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 (5 parameters, 3 required) and the absence of an output schema or annotations, the description is severely lacking. It does not explain what the workspace creation entails, what is returned, or how parameters like 'design_goal' should be used. This is insufficient for an agent to use the tool confidently.
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?
The input schema has 0% description coverage, and the tool description provides no additional meaning for any of the 5 parameters. Parameters like 'constraints' and 'payment_ref' are left entirely unexplained, so the agent cannot infer their purpose from the description.
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' and the resource 'ProtoGen CAD workspace', and specifies the target 'for another agent or workflow'. This distinguishes it from sibling tools like protogen__generate_cad_design or protogen__export_cad_design.
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, nor are there any prerequisites or exclusions. The description gives no context for appropriate usage 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?
With no annotations provided, the description carries the full burden. It labels the tool as 'Export' which suggests a read operation, but does not disclose side effects, security requirements, or what happens with the output. The payment_ref parameter hints at financial implications but remains unexplained.
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 efficiently names the action and outputs. However, it could be improved by structuring information about parameters and usage into discrete sentences.
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 output schema or detailed parameter explanations, the description is insufficient for an agent to confidently invoke the tool. The return format (e.g., file download, URL) is not mentioned, and payment requirements are opaque.
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?
Scheama description coverage is 0%, yet the description does not explain any of the three parameters (design_id, payment_ref, export_format). The export formats listed do not map to acceptable values for export_format, leaving the agent without critical input 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?
The description clearly states the tool exports a CAD design and lists three specific export formats (OpenSCAD, STEP contract metadata, manufacturing brief). This differentiates from sibling tools like protogen__generate_cad_design which creates designs rather than exporting them.
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 each export format, nor conditions for using this tool over alternatives. It does not mention prerequisites like payment that might be implied by the payment_ref parameter.
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 exist, so the description must disclose behavioral details. It only indicates a read operation (listing bonds) but omits information on pagination, authorization, rate limits, or the meaning of bond states. The absence of behavioral context limits transparency.
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 but includes a bracketed category prefix '[surety — bonding + ruling-gated slashing (risk transfer)]' that adds noise without aiding agent selection. The core sentence is concise, but the structure could be improved by removing the prefix or integrating it more effectively.
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 no output schema and a single parameter, the agent lacks critical information: return format, field descriptions, pagination behavior, and the meaning of bond states. The description does not compensate for these gaps, leaving the tool underspecified for effective use.
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 no parameter description (0% coverage). The description lists the valid filter values, adding meaning beyond the bare schema. However, it does not explain default behavior when state is null or how the output is structured, leaving gaps.
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 lists bonds and optionally filters by state with explicit values (POSTED|ACTIVE|RELEASED|EXHAUSTED). However, it does not explicitly differentiate from the sibling tool surety__bond_status, though 'list' vs 'status' implies different use cases.
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 surety__bond_status or other surety tools. The description only mentions the optional filter but lacks context on prerequisites or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It implies a read-only operation but does not explicitly state that it has no side effects, nor does it disclose any auth requirements or other behavioral traits. The cryptic phrase 'A-1 against the live canon' adds ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description wastes a full introductory sentence in brackets that seems to describe the overall system rather than the tool itself. The actual instruction is short, but the irrelevant preamble harms conciseness. It is not front-loaded with 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 and no parameters, the description should clearly explain what is returned. It only mentions 'modules and their LIVE/BLOCKED state (A-1 against the live canon)', which is incomplete. The agent cannot infer the output structure (e.g., names, IDs, timestamps).
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 0 parameters, so the baseline is 4. The description does not add any parameter meaning, but none is needed. It correctly indicates that the tool takes no arguments.
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: 'List ViridisOS modules and their LIVE/BLOCKED state'. While the preamble adds confusing context, the core purpose is specific and distinguishable from sibling tools like viridis_certify or viridis_bind_did.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or when not to use it. The description fails to help the agent decide if this is the right tool for the current task.
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 explains the verification method (recomputing hash), giving insight into behavior. However, with no annotations, it fails to disclose side effects, required permissions, or error conditions. Provides partial 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 concise—one sentence that includes a domain tag. It gets straight to the point with minimal waste, though the tag could be seen as extraneous.
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 (one unstructured parameter, no output schema, no annotations), the description is too sparse. It lacks details on input format, output, error handling, and sibling differentiation, leaving 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?
The description does not address the single parameter 'attestation'. With 0% schema description coverage, the tool needs to compensate but fails to clarify what constitutes a valid attestation object.
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: 'Verify an attestation by recomputing the entry hash.' It includes a domain tag that aids context. However, it does not differentiate from similarly named sibling tools like erc8004__verify_attestation or trust__verify_attestation.
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, nor any prerequisites or contextual hints. The description lacks explicit usage direction.
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 'self-description', implying a read-only operation, but does not confirm idempotency, side effects, or any prerequisites. The description is too vague to ensure safe invocation.
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 short (one sentence with a prefix). It is concise but lacks structure. The prefix '[escrow — trustless escrow & settlement (exactly-once)]' adds context but is not formatted clearly.
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 exists, so the description should explain what the tool returns. It only says 'self-description', which is insufficient for an agent to understand the output. The tool is simple, but with many sibling describe_agent tools, more detail would help.
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, so there is nothing to document. Baseline is 4 as the schema coverage is 100%.
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 'Fleet-standard self-description', clearly indicating it describes the escrow agent/fleet. It distinguishes from sibling describe_agent tools by the '[escrow — trustless escrow & settlement]' prefix. However, it doesn't specify what the description contains (e.g., capabilities, status), leaving some ambiguity.
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. Sibling tools include many other describe_agent tools for different fleets, but the description offers no context for selection.
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 mentions 'exactly-once' semantics and clarifies that refunding an OPEN escrow is a cancel. However, it does not disclose other behavioral traits like authentication needs, side effects, or error conditions.
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 extremely concise, consisting of two short sentences plus a prefix. Every word serves a purpose, and the key action is front-loaded.
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 lack of annotations and output schema, the description is insufficient. It omits return values, prerequisites, error scenarios, and authorization requirements. The tool has moderate complexity with state-based behavior, yet the description is too brief to fully equip an agent.
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?
The input schema has 2 parameters with 0% coverage (no descriptions in schema). The description does not mention either parameter, leaving the agent without any semantic guidance for 'reason' or 'escrow_id' beyond their 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 action (refund), resource (escrow), and allowed states (OPEN/FUNDED/DISPUTED). It also specifies the recipient (payer). However, it does not explicitly differentiate from sibling tools like release_escrow or dispute_escrow, missing an opportunity for 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?
The description provides state conditions (OPEN/FUNDED/DISPUTED) for when to use the tool, but it does not guide the agent on when to choose this tool over alternatives like release_escrow (likely for payee) or dispute_escrow. No comparisons are made.
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?
It discloses deterministic behavior and handling of unknown inputs, which adds value beyond the absence of annotations. However, it does not mention whether the tool is read-only or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the first sentence is slightly opaque ('deterministic map'). It could be clearer while maintaining 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 lack of output schema and minimal input description, the description is insufficient for the agent to use the tool correctly. It omits details on the activity object structure and return format.
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?
The sole parameter 'activity' is an open-ended object with no schema details in the description. Schema coverage is 0%, and the description provides no guidance on its structure, leaving the agent unable to construct valid input.
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 action ('Suggest') and the resource ('scope and Scope 3 category'), and distinguishes it from sibling tools like calculate_inventory. However, 'bundled deterministic map' is vague.
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 explains that no inference is used and unknown types return no suggestion, indicating when it applies. But it does not explicitly state when not to use it or compare with 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, the description must fully disclose behavior. It states the return values but does not mention side effects, permission requirements, idempotency, or error handling. The read-only nature is implicit but not confirmed.
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 short but includes a system context bracket ('[hive — ...]') that is not tool-specific. It achieves conciseness but at the cost of some focus. Structure is minimal; could be more tool-centric.
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 simple tool with one parameter and no output schema, the description provides only the return categories. It lacks details on error handling, return format, or typical use cases, making it incomplete for an agent to confidently use.
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?
The input schema has one parameter 'job_id' with no description (0% coverage). The tool description does not explain what a valid job_id is, how to obtain it, or any format restrictions. No added 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 states the verb 'Return' and the resource 'job state, plan hash, and live budget conservation books', which distinguishes it from sibling tools like hive__solve (creates jobs) and hive__audit_job (audits jobs). It 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?
The description implies the tool is for checking job status, but it does not explicitly state when to use it versus alternatives, nor does it provide prerequisites or exclusions. Usage context is inferred from the tool name and description, but not explicitly guided.
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 verification involves hash recomputation and ledger checking, implying a read operation with no side effects. However, it omits details such as permission requirements, error handling, or what happens if the certificate is invalid. With no annotations, the description provides moderate transparency.
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, which is concise but lacks structural elements like examples or required fields. It is front-loaded but overly brief given the complexity of the parameter.
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 (one nested object parameter, no output schema), the description is incomplete. It does not explain the certificate's required properties, expected output, or potential errors. The agent would need additional context to use this tool effectively.
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?
The sole parameter 'certificate' is an arbitrary object with additionalProperties: true, and the description does not clarify its expected structure. With 0% schema description coverage, the tool description adds no meaning beyond the raw schema, leaving the agent without guidance on how to construct valid input.
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 offset certificate by recomputing its hash and checking the ledger. It uses a specific verb ('Verify') and resource ('offset certificate'), and the action is distinct from siblings like 'verify_disbursement' and 'verify_retirement'.
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 'green-router__verify_green_certificate' or 'provenance__verify_certificate'. There is no mention of prerequisites, exclusions, or typical use cases.
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 exist, so description must fully disclose behavior. It mentions generating outputs but lacks details on side effects, permissions, rate limits, or what happens to input data. The tool likely performs computation without persistent changes, but no explicit statement.
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?
Single sentence efficiently conveys core purpose. The prefix adds context but is not essential. Concise but lacks sufficient detail for the task 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?
With no output schema and 2 parameters, description is too sparse. Missing return value format, error handling, expected structure of product_spec, and any constraints. Incomplete for an agent to reliably invoke.
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%. Description only hints at 'product_spec' indirectly but provides no structure or format details. 'payment_ref' parameter is completely ignored. Does not add meaningful semantics beyond parameter names.
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 clearly states the tool generates a manufacturing plan, BOM, DFM notes, and cost estimate from a product spec. It distinguishes from siblings like protogen__generate_cad_design by specifying the output type (manufacturing plan vs CAD design) and input (product spec).
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 protogen__generate_cad_design. No prerequisites, exclusions, or context provided. The description simply states what it does without usage context.
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 the core behavior (recomputing hash and checking ledger), implying a read-only verification. Since no annotations exist, the description carries the full burden, but it does not detail side effects, safety, or error states. Basic transparency is provided.
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 with one informative sentence plus a domain prefix. It is front-loaded and contains no redundant information. However, it could be more structured by listing expected input fields.
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 output schema, no annotations, and a vague parameter object, the description is insufficient. It does not explain the verification result (e.g., boolean, status object) or provide enough context for 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?
The single parameter 'certificate' is a generic object with no defined properties and 0% schema description coverage. The description only mentions 'recompute its content hash' but does not specify the object structure, required fields, or format, leaving the agent with minimal guidance.
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 'verify' and resource 'certificate', and explains the action: recompute its content hash and check the ledger. The prefix provides domain context. However, it does not differentiate from sibling tools like 'provenance__verify_artifact' or 'offsets__verify_certificate'.
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 lacks when-to-use, when-not-to-use, or any comparison with sibling 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. 'Self-description' implies a read-only operation that returns information about the agent itself, but no additional behavioral details (e.g., what it returns, whether it requires authentication, side effects) are disclosed. The description is 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a prefix). It is concise but lacks substance and does not fully explain the tool's purpose or behavior. It could be improved with more detail while remaining concise.
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 no parameters and no output schema, the description is minimally complete. It tells the agent that the tool provides a self-description of the covenant agent, but does not elaborate on the return structure or how it fits into the broader system. It meets the bare minimum.
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 the description covers this implicitly. Since there are no parameters to document, the baseline is 4. The description adds nothing beyond the schema, but that is acceptable here.
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 'Fleet-standard self-description' which indicates the tool provides a description of the agent. However, it is generic and does not distinguish this 'describe_agent' from the many other 'describe_agent' sibling tools from different modules. The prefix '[covenant — deny-by-default authority leases]' provides context but is not a clear verb+resource specification.
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 other 'describe_agent' tools or other tools. No when-not-to-use or alternative suggestions are provided. The description lacks any usage 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 provided, so the description bears full responsibility. It notes idempotent per feedback_id, but lacks details on side effects (e.g., overwriting existing data), authorization needs, or rate limits. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: context line, main purpose, item format, and idempotence note. It front-loads the main action but could be more structured for readability.
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, the description should explain return values. It does not. It also omits error cases, prerequisites, and full item structure (e.g., fields in feedback beyond those listed). The description is incomplete for a 3-parameter tool.
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 does not explain the three parameters (chain_id, token_id, feedback). It only describes the feedback item structure internally, failing to add meaning to the parameters themselves.
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 'Import', the resource 'ERC-8004 Reputation Registry feedback records', and the context 'for an agent'. This distinguishes it from sibling tools like erc8004__import_registration and erc8004__score_agent.
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 the item structure and mentions idempotence, but does not explicitly state when to use this tool versus alternatives (e.g., when to import versus other reputation operations). Usage context is implied but not clarified.
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 that the tool is paid after a free tier, involves retirement of offsets, and returns a certificate with Verra provenance. It does not mention idempotency, rate limits, error conditions, or required authentication. The behavioral traits are partially covered but not exhaustively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes marketing fluff (e.g., the bracket note, repeated mention of 'no retirement, no certificate'). It could be significantly condensed without losing meaning. The essential information is present but not efficiently organized.
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 the tool has one parameter, no output schema, and is part of a larger carbon-accounting system, the description gives a reasonable overview of the process (compute, pay, retire, receive certificate). However, it fails to clarify the expected parameter structure, the prerequisite steps (e.g., need a footprint quote), or the exact response format beyond 'machine-verifiable certificate'.
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 one parameter ('workload') with no description and schema coverage of 0%. The description only vaguely refers to 'compute the workload footprint' without specifying the expected structure or fields of the workload object. This leaves the agent with insufficient guidance on how to populate the parameter.
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 that the tool computes a workload footprint and retires verified offsets to return a machine-verifiable certificate. It uses specific verbs like 'compute' and 'retire' and distinguishes itself from sibling tools like green_route and verify_certificate, though not explicitly. The purpose is clear but could be more succinct.
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 that the tool is used after obtaining a footprint (possibly from green_route) and involves payment. It mentions a fail-closed invariant ('no retirement, no certificate'). However, it does not explicitly state when to use this tool versus alternatives like verify_certificate or list_certificates, nor does it provide prerequisites or 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?
No annotations provided. Description implies a read-only query but does not explicitly state it. No mention of side effects or required permissions.
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?
Very concise, no wasted words. The bracketed context note provides useful namespace info. Could be more front-loaded with the action verb.
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?
Adequately describes output fields (event count, total quantity, accrued minor units) but lacks detail on prerequisites, currency, or that the meter must exist.
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 does not elaborate on the 'meter_id' parameter beyond its name. No format or source info provided.
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 returns totals for a meter (event count, total quantity, accrued minor units). The verb 'get' or 'retrieve' is implied. It distinguishes from sibling tools like metering__list_meters or metering__record_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 guidance on when to use this vs alternatives (e.g., metering__usage_timeseries for time series). No prerequisites or conditions 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?
With no annotations, the description should disclose behavioral traits. It mentions read-only style content ('list all developmental agents') but does not explicitly state read-only nature, side effects, authorization needs, or any constraints (e.g., pagination). The term 'mount' is ambiguous.
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 but includes a verbose prefix that may be redundant. The main information is concise, but the structure is not optimally front-loaded as the prefix precedes the core description.
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 returns a list with summary counts, but lacks details on the output format, what the summary counts include, and any limitations. Since there is no output schema, more detail would be beneficial.
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, and schema coverage is 100% by default. The description does not need to add parameter semantics. A baseline of 4 is appropriate for a tool with no parameters.
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 returns 'all developmental agents on this mount, with summary counts,' which implies a list operation. It distinguishes from sibling tools like neurogenesis__get_agent by indicating a collection. However, the phrasing is somewhat implicit and the prefix adds noise, slightly reducing 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 is provided on when to use this tool versus alternatives such as neurogenesis__get_agent or other list tools. The description does not mention any prerequisites or context for using the tool.
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 provided; the description does not explicitly state that this is a read-only, non-destructive operation. The action of returning data is implied but not confirmed.
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 one sentence but includes a parenthetical domain name that isn't part of the action description. Could be streamlined without the brackets.
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 zero-parameter introspection tool with no output schema, the description adequately lists returned fields. However, structure or format of the output is not described, which could help.
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?
No parameters exist, so baseline 4 applies. The description adds no parameter-specific information, which is acceptable.
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 returns specific information about the agent (capabilities, version, etc.). The leading bracket phrase adds context but may be confusing. Distinction from sibling describe_agent tools is implicit via the domain prefix in the tool 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?
No guidance on when to use this tool versus other describe_agent tools. Given many siblings, explicit context would help but is missing.
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 'Return SmartScale health status' without detailing what the health status contains (e.g., boolean, detailed report) or whether it is a read-only operation. Lack of side-effect disclosure is acceptable for a health check, but more context would be helpful.
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 short but includes an unnecessary prefix that distracts from the core purpose. Could be simply 'Return SmartScale health status.' The prefix adds no value for this specific 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?
For a zero-parameter, no-output-schema health check, the description is minimally adequate. It fails to explain what the health status indicates or any prerequisites. A health check often needs to convey what is being checked (e.g., service availability, database connectivity).
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, and schema coverage is 100%. The description correctly indicates no parameters needed. Baseline for 0 params is 4, and the description adds no confusion.
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 'Return SmartScale health status,' which is a specific verb-resource pair. It distinguishes from sibling smartscale tools (photo instructions, describe, scale objects). However, the prefix '[smartscale — credit-card-calibrated visual measurement]' is generic and may cause confusion.
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. No mention of prerequisites or typical use cases. A health check tool might be used before other operations, but this is 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 bears full responsibility. It describes a read-like validation but does not disclose what happens on failure, return behavior, permission requirements, or rate limits. Minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a front-loaded domain context. However, it sacrifices detail for brevity, missing parameter and behavioral info.
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 one parameter and no output schema or annotations, the description is too minimal. It fails to explain the audit chain context, validation criteria, or result interpretation, leaving the agent under-informed.
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 does not mention the bond_id parameter or its format, constraints, or usage. The agent gets no guidance beyond the raw 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 validates the tamper-evident audit hash chain for a bond. It uses a specific verb (Validate) and resource (audit hash chain), distinguishing it from sibling tools like bond_status or slash_bond.
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 verifying audit integrity but provides no explicit guidance on when to use this tool versus other surety or verification tools. No when-not-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It implies a read-only operation by stating it returns data, but does not explicitly confirm no side effects, destructive actions, or prerequisites. For a history tool, this is minimally adequate, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with a tag summarizing the tool's domain. It is not verbose, but could be slightly more structured to separate the tag from the main 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?
The description lists what is returned, but no output schema exists. It lacks details on the format of the history (e.g., structure of outcomes, pagination, limits). For a tool that returns multiple pieces of data, more specificity would improve completeness.
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 one parameter (agent_id) with no description (0% coverage). The tool description does not mention the parameter, its type, or its role beyond 'for an agent.' This adds almost no value over the raw 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 that the tool returns 'Full outcome history + attestation count + current score for an agent,' specifying the resource and data returned. It distinguishes from siblings like trust__score_agent (which only returns score) and trust__attest (which deals with attestations). However, it could be more explicit about the action (e.g., 'Get' or 'Retrieve').
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 usage guidelines are provided. The description does not indicate when to use this tool vs. alternatives (e.g., trust__score_agent for just the score, trust__record_outcome for recording outcomes). An agent would need to infer use cases from the 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 carries full burden. It mentions decay weighting and neutral default score, but fails to disclose whether the tool is read-only, destructive, or requires specific permissions. It does say 'bridge to on-chain identity', implying a read operation, but not 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?
Two sentences with no fluff. Front-loaded with key identity information. However, it could include brief parameter hints without losing conciseness.
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?
Explains output (score and tier) and edge case (no feedback → 0.5). But 'tier' is not defined, and no output schema exists. For a simple scoring tool, it is mostly adequate but could be more precise.
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 has 3 parameters (chain_id, token_id, bridge_did) with 0% description coverage. The tool description does not explain these parameters at all, leaving their purpose and format completely unspecified.
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 clearly states it computes a decay-weighted trust score in [0,1] plus tier based on ERC-8004 feedback. It specifies 'bridge to ERC-8004 on-chain identity', distinguishing it from generic trust scoring tools like trust__score_agent.
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?
Implied usage context: it operates on 'imported ERC-8004 feedback'. However, it does not explicitly state when to use this tool versus alternatives (e.g., trust__score_agent), nor does it mention prerequisites or use cases.
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. It only says 'Fetch a past purchase / offset certificate by id' without disclosing behavior such as read-only nature, authentication requirements, or error conditions.
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 key action and resource. While efficient, it could include a bit more context without becoming verbose.
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 fetch-by-id operation, the description is minimally adequate. However, it lacks mention of what is returned (e.g., certificate details, purchase record) and any context about the offsets clearinghouse domain.
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 merely repeats 'by id', adding no semantic meaning to the purchase_id parameter beyond its name. No value is added over 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 'Fetch' and the resource 'purchase / offset certificate' with the identifier method 'by id'. It is specific and distinguishes from sibling tools like offsets__buy_offset or offsets__verify_certificate.
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. Siblings exist for buying, booking, or verifying offsets, but no context is given for choosing this fetch operation.
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. It only mentions it is a 'self-description' but does not explicitly state it is read-only, stateless, or free of side effects. The lack of behavioral detail is a gap.
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 is front-loaded with the tool context and covers the essential purpose. It is concise and avoids 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?
Given no output schema and no annotations, the description is minimally adequate for a standard describe tool. However, it could be more specific about the format or content of the description to aid agent decision-making.
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 coverage is complete. The description does not need to explain parameters. The mention of 'inputs' in the output is appropriate for a describe tool.
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 it is a self-description tool for the regulatory-radar agent, listing capabilities, inputs, and outputs. It distinguishes itself from sibling describe_agent tools by specifying the regulatory-radar 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 guidance is provided on when to use this tool versus alternatives like other describe_agent tools or other regulatory-radar tools. The agent is left to infer usage context.
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?
Description discloses that the full account key is returned once and only its SHA-256 and last four characters are retained, which adds behavioral insight beyond the schema. However, no annotations exist and other traits like authentication or rate limits are omitted.
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?
Description is two concise sentences. The initial bracket providing context is slightly extraneous but not harmful. Information is front-loaded.
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 simple tool with 1 parameter and no output schema, the description lacks clarity on the parameter and the return value (only key retention is mentioned). The agent is left with insufficient context to invoke 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 0% and the description does not explain the `account_ref` parameter, leaving its meaning unclear. The description fails to compensate 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?
Description clearly states 'Create a free account for bearer attribution' with specific verb and resource. It also provides context of B2B monthly seats but does not differentiate from sibling tools (e.g., identity__register_agent) which serve similar purposes in different modules.
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 context is implied by the module (subscriptions) and the description of a free account for bearer attribution, but no explicit guidance on when to use this over alternatives or exclusions is 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 burden. It does not disclose any behavioral traits such as side effects, permissions, rate limits, or safety (e.g., read-only vs mutation). The description only lists output fields, leaving the agent uncertain about operational impact.
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 a bracketed prefix that provides domain context. It is concise and front-loaded, but the prefix could be integrated more smoothly. Overall, it is efficient with minimal waste.
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 lists the specific items returned (fleet-standard version, catalog digest, security posture, etc.), which is fairly complete for a read-only retrieval tool. However, it lacks information about whether the tool requires authentication or any side effects, but for a simple describe operation, 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?
There are 0 parameters, and schema coverage is 100%. The description adds meaning by specifying the return fields, but since there are no parameters to document, the baseline is 3. The description explains what the tool does, compensating for the empty 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 states 'Return the fleet-standard version, catalog digest, security posture, lifecycle policy, and capabilities.' This is a specific verb+resource, clearly indicating the tool retrieves configuration details. However, it does not differentiate from sibling 'describe_agent' tools, but the subscription context is implied by the bracketed prefix.
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 vs alternatives. The description only states what it does; it does not provide context about when it is appropriate, prerequisites, or when to avoid it. Sibling tools with similar names suggest alternatives that are not distinguished.
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 must cover behavioral traits. It states the tool returns a current record, implying a read operation, but does not explicitly confirm idempotency, lack of side effects, error conditions, or authorization needs. The mention of 'ruling-gated slashing' adds domain context but not 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 very short and front-loaded with the key information. The bracketed prefix adds domain context, which may be helpful but is slightly redundant. Overall, every sentence earns its place, but the prefix could be merged or removed.
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 (1 required parameter, no output schema), the description conveys the return fields (state, balances, claims, audit head). However, it lacks details on output format, possible errors, or whether the bond record includes additional metadata, making it minimally complete.
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?
The input schema has 0% description coverage, and the description does not explain the bond_id parameter beyond its name. The agent receives no guidance on the format, source, or constraints of bond_id, which is critical for correct 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 retrieves the current record for a bond, including state, balances, claims, and audit head. It specifies the resource ('bond') and the action ('current record'), effectively distinguishing from sibling tools like surety__list_bonds or surety__file_claim.
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 surety__list_bonds or surety__price_bond. It does not indicate prerequisites, context, or exclusions, leaving the agent without decision criteria.
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 exist, so the description carries full burden. It mentions 'tamper-evident' but lacks details on authentication requirements, side effects, or reversibility. For a write operation, this is insufficient.
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 with front-loaded context in brackets. Every word adds value; no wasted space.
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 description of return values. For an issuance tool, understanding what is returned (e.g., attestation ID, proof) is important. Missing.
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 adds no meaning to the parameters 'claim' and 'agent_id'. Default for 'claim' is given in schema but not explained. The description should compensate but does not.
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 ('Issue') and the resource ('tamper-evident (hash-chained) trust attestation'), effectively distinguishing it from sibling tools like trust__verify_attestation and trust__score_agent.
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. With numerous sibling trust tools, explicit context or exclusion criteria would be beneficial.
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 behavioral disclosure. It mentions 'content-addressed attestation' and 'verifiable', but does not specify whether the tool creates a new record, what permissions are required, or what side effects occur. Behavioral transparency is insufficient.
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 efficiently conveys the tool's purpose. It is front-loaded with a domain tag in brackets. While concise, the brackets are somewhat unnecessary and could be removed, but overall it is well-structured for quick scanning.
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 simplicity (one parameter, no output schema, no annotations), the description should still clarify the outcome (e.g., returns an attestation ID or proof), potential errors, and required context. It falls short by not explaining what the agent should expect after issuing an attestation.
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%, yet the description does not elaborate on the 'entry_id' parameter beyond the phrase 'for a ledger entry'. It fails to add meaning about the parameter format, constraints, or how to obtain it. The description does not compensate for missing 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 ('Issue a content-addressed attestation'), the target resource ('ledger entry'), and the context ('verifiable green-compute / energy claim'). It is specific and distinguishes from sibling tools like 'verify_attestation'.
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 attestation of a ledger entry is needed, but it does not explicitly state when to use this tool versus alternatives such as 'verify_attestation' or 'record_work'. No exclusion criteria or prerequisites are mentioned.
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 adds behavioral context by stating that it 'produces an order-independent, content-addressed (unsigned) binding attestation.' Since no annotations are provided, the description carries the full burden and provides useful insight into the output's characteristics, though it omits details like authorization requirements or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2 sentences) and front-loaded with the purpose. The first sentence is a bracketed title that could be integrated, but overall it avoids unnecessary verbosity.
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 4 parameters, no output schema, and no annotations, the description should provide more context (e.g., explanation of fleet DID, ERC-8004 identity, return format). It does not cover what the binding attestation looks like or how to interpret the result, leaving significant gaps for correct 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?
The input schema has 4 parameters (chain_id, token_id, fleet_did, proof_note) with 0% schema description coverage. The description adds no explanation or meaning to any parameter, leaving the agent to infer their purpose from names alone. This is insufficient given the lack of 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 action: 'Bind a fleet DID to an ERC-8004 identity.' This is a specific verb+resource combination, and it distinguishes itself from sibling tools like erc8004__import_registration or erc8004__resolve_agent by focusing on binding identities.
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 does not provide any guidance on when to use this tool versus alternatives like erc8004__import_registration or export_attestation. It lacks explicit context on prerequisites, exclusions, or when not to use it.
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 exactly-once idempotency semantics and that repeated calls return the existing record. However, without annotations, it lacks details on side effects, error conditions, or state transitions beyond the initial state constraint.
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 that communicates core behavior efficiently. The prefix '[escrow — trustless escrow & settlement (exactly-once)]' adds context but could be trimmed or integrated.
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 no output schema and incomplete parameter documentation, the description does not fully equip an agent to use the tool. Missing return value format, error cases, and detailed parameter semantics reduce completeness.
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?
With 0% schema description coverage, the description adds no meaning to parameters. It does not explain 'escrow_id' format or 'delivery_proof' purpose, leaving the agent to infer from name and type alone.
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 'Release' and the resource 'escrow' with specific state conditions (FUNDED/DISPUTED). It distinguishes this tool from potential alternatives by being the sole escrow release tool among siblings.
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 escrow is funded or disputed but provides no guidance on when not to use, prerequisites, or alternative tools. There is no mention of required authorization or state validation.
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 implies a read-only operation ('self-description'), but does not explicitly disclose side effects, authentication needs, or data sensitivity. Since no annotations are provided, the description carries the burden, and stating 'Fleet-standard' hints at conventions but could be more 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 very concise, consisting of one sentence with a bracketed namespace hint. It is front-loaded and efficient, but could benefit from slightly more detail without becoming verbose.
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 zero parameters, no output schema, and no annotations, the description is minimally adequate. However, for a self-description tool in a large system with many similar tools, additional context about the returned data (e.g., agent capabilities, DID) 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 input schema is empty, so schema coverage is 100%. The description does not add parameter-specific meaning because there are none, but the baseline score of 3 is appropriate as the schema already fully defines the no-parameter case.
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 it is for 'verifiable agent identity + capability discovery' and 'Fleet-standard self-description', which clearly indicates the tool's purpose of providing a self-descriptive metadata for an identity agent. It distinguishes from sibling describe_agent tools by the identity namespace, but could be more specific about the exact output.
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 other describe_agent tools from different namespaces (e.g., arbitration__describe_agent, offsets__describe_agent) or versus other identity tools like identity__resolve_agent. The agent must 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?
No annotations are provided, so the description carries full burden. It states 'salt/digest stay hidden' but does not disclose other behaviors such as whether the tool is read-only, what errors may occur (e.g., if commitment_id doesn't exist), or any authorization needs. Minimal behavioral context is given.
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 a namespace prefix, which is concise. However, the prefix adds some redundancy. It is front-loaded but lacks structural elements like bullet points or clear separation of behavior and usage.
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 simple (single parameter, no output schema), but the description fails to indicate what the output represents (e.g., status enum, timestamps), error conditions (e.g., missing commitment), or any side effects. It feels incomplete for a status-check tool.
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% coverage, meaning the description must explain parameters. It only mentions 'commitment_id' in the input schema title, and the description does not add any semantics (e.g., format, example, or what it represents beyond the name). The description adds no 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 clearly states it provides the current record for a commitment in the pre-reveal phase, distinguishing it from sibling tools like notary__commit (to create), notary__reveal (to reveal), and notary__verify (to verify). The verb 'record' and resource 'commitment status' are specific.
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 'pre-reveal' implicitly suggests using this tool before revealing, but there is no explicit guidance on when to use this versus alternatives like notary__list_commitments or notary__verify. No 'when not to use' or comparison to siblings is 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, the description carries full burden for behavioral disclosure. It reveals that project_id is immutable after registration, which is useful. But it omits other key behaviors: idempotency, duplicate handling, error conditions, return value, or permissions needed. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded: it opens with context, then the main action. Every sentence adds value without redundancy. Minor improvement could be structuring key constraints (e.g., required params) more explicitly, but it is already 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?
Given no output schema, no parameter descriptions, and no annotations, the description is the sole source. It covers purpose and two constraints but fails to explain the effect of optional parameters, success/failure responses, or how this tool fits into the offsets workflow (e.g., after registration, use offsets__list_projects or offsets__project_funding). This incompleteness hampers correct usage.
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%, so description must compensate. It adds meaning for verification_ref (D-Score/land-verification/registry id) and project_id (immutable), but does not explain name, location, beneficiary, methodology, or registry_ref. The required parameters are partially covered, but the optional ones are left entirely to the schema (which has no descriptions), leaving semantic gaps.
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 ('Register a VERIFIED restoration project') and the resource (project within a verified-credit carbon offset clearinghouse). It distinguishes from other offsets tools by specifying registration with verification_ref required, and notes that project_id is immutable, setting it apart from tools that list or fund projects.
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: only verified conservation projects should be registered (since verification_ref is required and 'only verified conservation is funded'). However, it does not explicitly state when not to use this tool or suggest alternatives like offsets__list_projects or offsets__project_funding.
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 provided, so description carries full burden. It only says 'self-description' but does not disclose read-only nature, authentication needs, or response behavior. For a simple describe tool, it is adequate but minimal.
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?
Extremely concise (one short sentence). Front-loaded with domain context. However, it could be slightly more informative without becoming verbose. Still appropriately sized.
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 simplicity, the description is vague ('Fleet-standard self-description') and does not specify what the output contains. With no output schema, the agent has no idea what to expect. Also fails to distinguish from sibling describe 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?
No parameters exist in schema (0), so description adds no parameter info. Baseline score of 4 applies as per guidelines for zero-parameter tools.
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 states it's a 'self-description' tool for the provenance domain, but doesn't differentiate from many sibling describe_agent tools (e.g., neurogenesis__describe_agent, notary__describe_agent). The domain prefix provides some context, but the purpose is not fully distinctive.
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. With multiple describe_agent siblings, the agent receives no criteria for choosing this one. The description lacks any contextual cues for usage.
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 burden. It only states it returns instructions, with no details on format, side effects, or prerequisites. Minimal disclosure.
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 two sentences, front-loaded with context. No unnecessary words, but the bracketed prefix is somewhat redundant with the tool name.
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 2 undocumented parameters and no output schema, the description should explain parameter usage and output format. It does neither, leaving significant gaps.
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 coverage is 0%; the description does not mention the two parameters (measurement_goal, objects_to_measure) or how they affect the output. The agent cannot infer parameter meaning from the description.
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 returns user-facing capture instructions for credit-card calibrated measurement, and explicitly says to use it before asking for a photo. This distinguishes it from the sibling tool that likely processes the photo.
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 timing: 'Use this before asking for a photo.' It doesn't mention when not to use or alternatives, but the purpose is clear enough in context of siblings.
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 zero annotations, the description must disclose behavioral traits. It mentions idempotency and that a newly created account receives its key once. However, it does not clarify side effects (e.g., billing, charging), permission requirements, or error handling. Some transparency, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a bracketed prefix ('[subscriptions — B2B monthly seats...]') that is more like a category than essential info. The core is two sentences. The prefix could be removed without losing clarity, so it is not as concise as it could be.
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 has one parameter, no output schema, and no annotations, the description is minimally adequate. It explains the core action and idempotency. But it lacks details on response, errors, and prerequisites, which leaves the agent with some uncertainty.
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 0% coverage (no parameter descriptions). The description only implies the parameter is a Stripe session or subscription ID through the action phrase 'Pull-verify a Stripe session/subscription.' It does not explain format, validation, or what constitutes a valid ID, so it adds minimal meaning beyond the parameter 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 action: 'Pull-verify a Stripe session/subscription and idempotently activate its exact subscription period.' It uses specific verbs (pull-verify, activate) and identifies the resource (Stripe session/subscription, subscription period). This distinguishes it from siblings like create_checkout_link or subscription_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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it relates to sibling tools like create_checkout_link or subscription_status. The context is purely operational.
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 fully bears the burden of behavioral disclosure. It only states what is returned (capabilities, version, pricing) without mentioning any behavioral traits such as side effects, idempotency, or authentication requirements. The description does not address whether the tool is read-only or has other behavioral 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 concise sentence that immediately conveys the tool's purpose. The bracketed prefix provides context without unnecessary verbosity. 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?
Given the absence of parameters, output schema, and annotations, the description is minimal. For a simple 'describe' tool, it provides the essential information about what is returned but lacks completeness regarding the nature of the output (e.g., format), potential variations, or any error conditions. It is adequate but could be improved with more detail.
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, and schema coverage is 100% because there are no parameters to describe. Per the scoring rules, the baseline is 4 for 0 parameters, and the description does not need to add parameter-level 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 verb 'Return' and the resource 'fleet-standard capabilities, version, and pricing', and the bracketed prefix specifies the taxcredit-engine domain. However, it does not explicitly differentiate from other describe_agent tools beyond the prefix.
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 given on when to use this tool instead of similar describe_agent tools from other namespaces (e.g., neurogenesis, notary, offsets). The description lacks context about appropriate use cases or 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?
No annotations are provided, so the description carries the full burden. It discloses that any change in amount, fact, rule step, or source digest causes failure, offering some behavioral insight. However, it does not state whether the operation is read-only, what the response format is, or any potential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single informative sentence after the bracketed context. No redundant information is present. The structure is efficient, though the bracketed prefix may be a repeated pattern.
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 with no output schema, the description covers the purpose, input format, and failure condition moderately well. However, it omits details on output semantics (e.g., boolean pass/fail) and prerequisites, leaving 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?
With 0% schema coverage, the description adds meaning by stating 'Pass the prior result object as JSON', clarifying that result_json should contain the full prior result. However, it does not specify the expected structure or provide examples, leaving the agent to infer 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 it verifies an engine result's audit_sha256, specifying the action (verify) and resource (tax credit engine result). The bracketed context provides domain scope, but does not explicitly differentiate from sibling verification tools such as verify_artifact or verify_certificate.
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. It implies use after a calculation, but does not mention when not to use it or provide comparisons with other verify tools. The description lacks usage context.
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 must carry the burden. It mentions 'decay-weighted reputation' and the 3x penalty for security incidents, adding some behavioral context. However, it does not disclose side effects (e.g., reputation update, idempotency) or authorization needs.
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 (one sentence plus a list) and front-loaded with purpose. The bracketed prefix adds minor clutter but does not hinder 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?
With 5 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain non-obvious parameters (e.g., weight for weighting outcomes) and does not mention return value or side effects, leaving gaps 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 0%, so the description must explain parameters. Only 'kind' is documented with its enumerated values. Parameters like 'note', 'weight', and 'counterparty' remain unexplained, leaving the agent to guess their 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: 'Record an interaction outcome for an agent.' It lists all possible kinds and notes a special penalty for security incidents. This distinguishes it from sibling tools like trust__attest (attestations) and trust__score_agent (score retrieval).
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. Does not specify prerequisites, when not to use, or compare to sibling tools. The description simply states what it does.
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 provided, so description must disclose behavior. It only states the verification method (recompute hash) but does not mention side effects, auth requirements, rate limits, or whether it is read-only. Minimal 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 extremely concise—a single sentence plus a domain prefix. It wastes no words but could benefit from more structure (e.g., separating purpose from method).
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 no output schema and no annotations, the description leaves out crucial context: what the verification result looks like, expected format, or any prerequisites. Incomplete for confident tool 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 0% and the description adds no meaning to agent_id or attestation_id beyond their names. With no parameter elaboration, the description fails to aid correct parameter usage.
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 'Verify a previously issued attestation by recomputing its hash,' specifying the action (verify), resource (attestation), and method (recompute hash). The bracketed prefix provides domain context distinguishing it from sibling tools like trust__attest.
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 (to verify an attestation) but lacks explicit guidance on when not to use or alternatives. No mention of prerequisites or comparison to related tools like notary__verify.
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 must carry the burden. It states the tool recomputes a hash chain and fee ledger, suggesting a read-only verification, but does not disclose side effects, authentication requirements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and a bracketed tagline. The tagline is promotional but short. The core behavior is stated concisely, though the tagline could be removed to improve 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?
With no output schema and no annotations, the description lacks details on return values, error conditions, or prerequisites. For a single-parameter tool, the description does not fully equip an agent to use 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?
The only parameter 'service_id' has 0% schema description coverage and the tool description does not add any meaning beyond the name. The agent must infer its purpose (identifying the service) from context.
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 'recompute[s] a service's full receipt hash chain and fee ledger', giving a specific verb and resource. It distinguishes from siblings like 'get_receipt' (which retrieves individual receipts) and 'list_services' (which lists services).
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 mentions 'Any party can audit' implying use for auditing, but does not explicitly state when to use or not use this tool, nor does it compare to alternatives like 'get_receipt' for retrieval of specific receipts.
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 traits (e.g., side effects, read-only nature). It only states what it returns, leaving the agent to infer safety.
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 a domain prefix. It is efficient but the phrasing 'demand-side agent/collective discovery' may be cryptic. Still, it is not verbose.
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 parameters and no output schema, the description covers the return value (capabilities and input contract). It is adequate but could provide more detail on format or scope.
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 schema coverage is 100%. The description does not need to add parameter meaning; baseline is 4.
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 it returns capabilities and input contract, and hints at the domain 'demand-side agent/collective discovery'. It is reasonably clear but lacks specificity on what capabilities are, and does not distinguish from many sibling describe_agent tools beyond the wavefunction prefix.
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 sibling describe_agent tools. No exclusions or context 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, the description must disclose behavioral traits. It mentions independence from compute work, which is helpful, but omits side effects, authentication requirements, rate limits, or return behavior upon success/failure. For a verification tool, this is minimal 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 short and front-loaded with the core action. The bracket prefix is slightly noisy but not a major distraction. The single sentence is efficient, though it could be trimmed.
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 one parameter and no output schema. The description covers the basic purpose and a key behavioral aspect (independence). However, it lacks details about the verification result format (e.g., Boolean, hash, error messages), which would help an agent interpret the response.
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%, so the description should elaborate on parameters. The only parameter, agent_id, is not explained beyond what the schema provides (type string). The description only says 'an agent's inventory hash chain,' which implicitly links agent_id to the agent but adds no semantic detail.
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 agent's inventory hash chain, using distinct verbs and specifying the resource. The phrase 'independently of compute work' helps distinguish it from sibling tools like verify_chain that likely verify compute work chains.
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 inventory hash chains without providing explicit guidance on when to use it versus alternatives like compute-ledger__verify_chain. No exclusions or alternative mentions 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?
No annotations are present, so the description must carry the behavioral burden. It merely states it returns capabilities and input contract, but does not disclose any side effects, permissions, or safety guarantees.
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, front-loaded with the module context header. Every word earns its keep with no 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 simple describe agent tool with no parameters and no output schema, the description provides sufficient context for what the tool does. However, it could elaborate on the 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?
There are no parameters, so the schema already covers 100%. The description adds nothing about parameters, but none are needed. Baseline 4 is appropriate as no improvement is possible.
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 that the tool returns the bridge's capabilities and input contract. It is specific enough to distinguish from sibling tools like 'resolve_agent' or 'import_registration'.
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 context about prerequisites or typical scenarios 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?
Describes return type (capabilities and input contract) but does not mention side effects or safety; no annotations provided, so description carries burden but is minimal.
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?
Single sentence after header; concise but header could be separated for clarity.
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?
Adequate for a simple describe tool, but no mention of output format or differentiation from other describe_agent tools; lacks detail.
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?
No parameters exist, so schema coverage is 100%; description correctly indicates no inputs needed, exceeding 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 states the tool returns capabilities and input contract, but the bracketed header mixes overall agent purpose with tool behavior, causing minor confusion.
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 describe_agent over sibling describe_agent tools from different domains; lacks context for 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, the description bears full responsibility for behavioral disclosure. It only states it returns capabilities and input contract, with no mention of permissions, side effects, or other 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.
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 context. Every word adds value, no 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?
Given zero parameters and no output schema, the description adequately covers the tool's purpose. It could elaborate on the output format or examples of capabilities, but it is sufficient for an introspection 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 schema coverage is 100%. Per guidelines, baseline 4 is appropriate; no additional parameter information is needed.
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 returns 'capabilities and input contract' for the notary domain. The domain prefix in brackets provides context, distinguishing it from other describe_agent tools among siblings.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it specify any prerequisites or limitations.
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 includes 'Read-only' and describes the content (verified credits with provenance). However, without annotations, it does not disclose whether authentication is needed, rate limits, or caching behavior. The retirement split info is somewhat tangential.
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 (three sentences) and front-loaded with the core concept. The initial bracketed label '[offsets — ...]' is slightly redundant but does not significantly detract. Every sentence adds value, though the retirement split may be better placed elsewhere.
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 has no parameters and no output schema, the description should detail the expected response. It mentions that credits have project id, serial, and vintage, but does not confirm the output structure (e.g., array, pagination). This is 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?
No parameters exist, so the burden on the description is minimal. The schema coverage is 100% (empty), and the description appropriately avoids adding parameter details. Baseline score of 4 applies per the rules for 0 parameters.
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 tool as providing the tradeable Verra VCS book of verified credits with provenance details. It explicitly states 'Read-only,' which helps distinguish it as a query tool. However, it lacks an action verb like 'list' or 'get,' and the purpose is implied rather than directly stated.
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 siblings such as 'offsets__list_credit' or 'offsets__verra_retirement_record'. The description does not mention alternatives, prerequisites, or context for use.
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 provided; the description does not disclose whether the operation is read-only, has side effects, requires specific permissions, or what the output format is. Only implicit that it recomputes values.
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 with essential information and domain context; no unnecessary content. Front-loaded with 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?
Missing output description; given no output schema, the description should explain what the tool returns after recomputation. Adequate for a simple 1-param tool but 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?
The parameter result_json has no schema description; the description only states to pass the prior result object as JSON, lacking structure or format details. This adds some value but insufficient for 0% 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 recomputes a takeoff audit hash, notary payload, pack currency, and QT9 unit-resolved conservation, which is a specific verification action distinct from other quantity-takeoff tools like calculate_takeoff.
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 verification tool versus alternative takeoff tools or other verify tools. The description does not provide context for selection.
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 pricing ($0.25 per call after 10 free calls/day) and payment methods, but does not mention whether the tool is read-only, any side effects, authentication requirements, rate limits beyond the free tier, or data freshness.
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 verbose, including a preamble prefix and detailed payment instructions that could be separated or shortened. The core functionality is front-loaded, but the overall length and inclusion of non-essential details reduce conciseness.
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 mentions return values (regulations with urgency flags and effective dates) and payment flow, but lacks details on error handling, response format, or the scope of sector values. No output schema is provided, so more context would be beneficial for a tool with 3 parameters and no annotations.
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 description explains 'jurisdiction' and 'sector' (optionally filtered by sector) but does not describe the 'payment_ref' parameter. Since schema description coverage is 0%, the description should add meaning for all three parameters; it partially does for two.
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 scans the regulatory landscape for a jurisdiction, optionally filtered by sector, and returns regulations with urgency flags and effective dates. The verb 'scan' and the resource are specific, distinguishing it from sibling tools like 'assess_compliance' and 'monitor_changes'.
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 regulatory-radar__assess_compliance or regulatory-radar__monitor_changes. It does not specify prerequisites or contexts where the tool is 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?
No annotations are present, so the description must disclose all behavioral traits. It only states it's a retrieval operation ('get') without detailing side effects, permissions, rate limits, or return 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-structured sentence with a context tag, making it concise and front-loaded. However, the context tag adds little value.
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 is minimal and does not fully compensate for the lack of output schema or annotations. While it hints at lineage information, the overall completeness is adequate but leaves gaps about response structure.
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?
With 0% schema description coverage, the description fails to explain the 'plan_id' parameter beyond its existence. No details on format, validation, or expected values are provided.
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 one exact monthly plan and its versioned catalog lineage, distinguishing it from sibling tools like 'list_plans' which presumably returns multiple plans.
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 specific plan is needed by ID, but does not provide explicit guidance on when to use this tool versus alternatives like 'list_plans' or 'mrr_summary'.
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?
Discloses bond fee computation and freezing at post, and principal unit convention. However, with no annotations, description carries full burden; lacks information on side effects, authorization, or what happens after posting.
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?
Three sentences in a compact header format. Efficiently conveys key points, though the title-like prefix adds marginal value. No wasted sentences.
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 5 parameters, no output schema, and no annotations, the description is incomplete. It covers only two parameters and omits return value, side effects, and full 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 coverage is 0%; description explains principal (minor units) and expires_at (ISO-8601) but completely omits coverage, currency, and principal_agent. Adds some meaning but leaves 3 params 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?
Description clearly states 'Post a surety bond behind an agent's promises' which is a specific verb-resource action. Distinguishes from siblings like activate, status, claim, etc. by the core action of posting.
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 versus alternative tools (e.g., when to activate or release). Implies usage for initial bond posting but lacks specifics on prerequisites or contraindications.
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 provided, so description alone must disclose behavior. It indicates a write operation ('attach') but does not mention idempotency, overwrite semantics, prerequisites (e.g., case must exist), or side effects. Only the score range is specified.
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?
Extremely concise: one sentence plus domain bracket. No redundant words. Front-loaded with context and action. Every part adds value.
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?
Gives a reasonable overview of function but lacks operational details like return value (no output schema), error conditions, or lifecycle context. For a simple mutation with nested objects, more information would be helpful but not severely deficient.
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%. The description partially explains the 'scores' parameter (party->[0,1]) but does not describe 'case_id' at all. Leaves meaning of both parameters incomplete, especially for an agent unfamiliar with the domain.
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 states verb 'attach' and resource 'trust-oracle reputation scores', specifies party->[0,1] range. Distinct from sibling arbitration tools (file_case, rule, etc.) which have different purposes. Domain bracket adds context.
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?
No explicit when-to-use or when-not-to-use guidance. Implies usage before a ruling but does not contrast with other arbitration tools like rule or submit_evidence. Lacks alternative recommendations.
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 deterministic, read-only behavior but does not detail consequences of mismatch, return format, or authorization needs, leaving 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 a single sentence of 22 words, front-loading the category, with no unnecessary words. Every phrase 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?
For a one-parameter verification tool with no output schema, the description explains the core action but omits return value details, error conditions, and prerequisites, 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning beyond the schema. The single parameter case_id is only identified by name, with no additional semantics or usage context provided.
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 recomputes a ruling from evidence and trust inputs and checks against stored allocation, using a specific verb ('recompute and check') and resource ('ruling'), distinguishing it from siblings as machine-checkable justice.
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 after a ruling is made but does not explicitly state when to use this tool versus alternatives like arbitration__rule or arbitration__get_case, nor does it provide exclusions or prerequisites.
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 must fully disclose behavioral traits. It only mentions the return of a covenant_id and gives parameter hints, but omits important details like whether the operation is destructive, idempotent, or requires specific authentication. The mutation nature is implied 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at two sentences, with the purpose front-loaded in brackets. It avoids extraneous content, though a more structured breakdown of parameters would improve readability.
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 no output schema, no annotations, and five required params, the description covers core usage but lacks detail on return value structure and omitted parameter explanations. It provides enough for basic invocation but not for comprehensive 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 has no descriptions (0% coverage), so the description must compensate. It clarifies that scopes support wildcards, budget_minor is a spend ceiling in minor units, and expires_at is ISO-8601. However, it does not explain principal or agent_id beyond their names.
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 granting a covenant, an explicit lease of authority. The verb 'Grant' and noun 'covenant' are specific, and the context of 'deny-by-default authority leases' distinguishes it from sibling tools that perform other agent-related actions like deletion or description.
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 granting authority but does not explicitly state when to use it vs alternatives like covenant revocation or other agent management tools. It provides no guidance on preconditions, when not to use, 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?
With no annotations, the description must disclose behavioral traits. It states the tool lists covenants but does not mention pagination, default state filter, ordering, read-only nature, or any side effects. These are critical gaps for a listing 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 concise (one sentence plus a prefixed domain hint) and front-loaded with the key action. The prefix in brackets is non-standard but adds context. No wasted words, though the prefix could be integrated more cleanly.
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 list tool with 2 optional parameters and no output schema, the description covers purpose and filter options. However, it lacks return format details (e.g., list of IDs, full objects), pagination behavior, and result limits, leaving an agent partially informed.
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 0%, so the description must compensate. It adds basic meaning by listing filterable fields (state with example values, agent_id) but does not specify agent_id format or whether state values are exhaustive. Partial improvement over schema alone.
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 'list', the resource 'covenants', and specifies optional filters by state (ACTIVE|REVOKED|EXPIRED) and agent. It distinguishes this tool from siblings like grant, revoke, or status, which involve different actions on covenants.
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 listing covenants with optional filters, but does not explicitly state when to prefer this tool over alternatives like covenant_status (for a single covenant) or when not to use it. No exclusions or context for selection 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 provided, so the description must convey behavioral traits. It implies a read-only operation but does not disclose authentication needs, rate limits, or any side effects. The description is minimal.
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: a contextual prefix and the action statement. It is concise and front-loaded with the key purpose, though the bracketed information may be slightly extraneous.
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 zero-parameter, no-output-schema tool, the description provides a modest list of return categories (capabilities, actions, invariants, pricing). However, it lacks specifics on format or structure, and could be more informative.
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 100% coverage, so baseline is 4. The description appropriately does not mention parameters, adding no extra meaning but also not detracting.
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 explicitly states 'Return fleet-standard capabilities, actions, invariants, and pricing,' which clearly identifies the action (return) and the resource (fleet-standard data). The bracket prefix distinguishes the hive module from sibling describe_agent tools in other modules.
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. The description does not mention prerequisites, when to avoid use, or how it fits into a workflow with sibling 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 mentions a key behavioral trait (never trusts the embedded hash), which adds transparency. However, it does not disclose whether the tool is read-only, requires authentication, or has side effects. Given the simple nature, more disclosure would be beneficial.
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, consisting of a single sentence plus a bracketed prefix. The prefix provides context about the hive system but is not strictly necessary for tool usage. The sentence is clear and efficient, with no wasted words.
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 simple with one parameter and no output schema, so the description should fully explain what the tool does and returns. It explains the core logic but does not specify the return format (e.g., a boolean, a string, or object indicating match or mismatch). Error conditions or prerequisites are also omitted. This leaves gaps for an AI agent.
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 one required parameter 'audit_json' with no description (0% coverage). The description does not mention the parameter name or provide format details. 'Presented lineage' is vague and does not explicitly map to the parameter. The description fails to compensate for the lack of 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: to recompute an audit digest from a given lineage, never trusting the embedded hash, and report whether it matches a job the hive ran. The verb 'recompute' and 'report' are specific, and it distinguishes from siblings like hive__audit_job by emphasizing the distrust of the embedded hash.
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 does not explicitly guide on when to use this tool versus alternatives such as hive__audit_job or other verification tools. It implies usage for verifying audit integrity, but lacks explicit context or when-not-to-use guidance. The sibling list includes many similar tools, so clearer guidance would help.
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 fully disclose behavior. It mentions optional status filtering with valid values (ACTIVE|REVOKED), which is helpful. However, it does not state whether the operation is read-only, if pagination exists, or any ordering of results. This is adequate for a simple list but not fully 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 extremely concise: two sentences with no filler. The context bracket is front-loaded, and every word adds value. 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?
Given the simplicity (1 parameter, no output schema, no annotations), the description covers the essential purpose and parameter semantics. However, it omits any description of the return value, which would be helpful for an agent to understand what information the registration list contains.
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 0%, so the description must compensate. It clearly explains the 'status' parameter, listing the allowed values (ACTIVE|REVOKED) and that it's optional. This adds meaningful guidance beyond the schema's minimal type definition.
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 lists registrations with optional status filtering. The bracket prefix '[identity — verifiable agent identity + capability discovery]' provides context, distinguishing it from other identity tools like identity__register_agent or identity__resolve_agent. However, it could be more precise about what constitutes a 'registration' in this 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 on when to use this tool versus alternatives such as identity__discover_agents or erc8004__list_registrations. The description only implies the scope via the identity prefix, but fails to specify use cases or 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?
No annotations are provided, so the description carries the burden. It discloses read-only nature, pagination via next_cursor, and test-event exclusion. However, it lacks details on rate limits, authentication, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with front-loaded key information ('Read usage events (paginated, read-only)') followed by a list of filters. It is concise and clear, though slightly dense.
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 10 parameters, no output schema, and no annotations, the description covers the main purpose and filters but lacks details on return format, pagination mechanics, and parameter constraints. It is adequate 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 description coverage is 0%, so the description must compensate. It lists filters and hints at enum values (e.g., consumer_class: internal|external|unknown; outcome: ok|error), but does not provide full value sets or format details for parameters like since/until.
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 it reads usage events, is paginated, and read-only. It lists filters, making the purpose specific. However, it does not explicitly differentiate from sibling tools like metering__usage_summary or metering__usage_timeseries.
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 enumerates filters and mentions test-flagged event exclusion, providing usage context. It does not give explicit when-to-use or alternatives, leaving some ambiguity.
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 provided, so description carries full burden. It states the tool registers a profile but does not disclose side effects, idempotency, or whether updates are allowed. The statement about routing not inventing capacity is more about the system than the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with a lengthy preamble about developmental agents and Wu Wei compute routing that adds context but is not strictly necessary. The core tool information is present but could be more concise.
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 complex domain and no output schema, the description reasonably explains what a profile is and its fields. However, it lacks details on uniqueness constraints, whether registration overwrites, or how lookup/update works, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully by listing all expected fields (id, kind?, quality_score, etc.) along with types and constraints like [0,1] for quality_score. This is essential for an agent to correctly structure the profile object.
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 verb 'register' and resource 'compute profile' are clear. The description distinguishes this tool from siblings like 'neurogenesis__compute_efficiency_report' and 'neurogenesis__route_task' by specifying that it registers an execution profile for compute routing.
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?
No explicit guidance on when to use vs alternatives. The phrase 'Profiles are yours — routing never invents capacity' implies that profiles must be registered before use, but does not mention when not to use this tool or suggest 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?
No annotations exist, so description carries full burden. It details the effects of success/failure on edges, mentions safety axioms (NG1), and states it returns developmental-ledger events. This is more transparent than 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compound sentence that conveys core behavior, but includes a bracket header that adds noise. It is moderately concise but could be restructured for clarity.
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 complexity of the neurogenesis domain and lack of output schema, the description covers the evolution process, parameter structure, and return type. Minor gaps exist but overall it is quite 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 0%, but description compensates partially by listing expected fields in the evaluation object (task_id, task_type, success_score, etc.). However, it does not describe the agent_id parameter or that evaluation is an object with additionalProperties.
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 verb 'Evolve' and resource 'agent with one task outcome', and specifies the evaluation fields. It clearly distinguishes from sibling neurogenesis tools like create_agent or route_task by focusing on evaluation submission.
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 vs alternatives. The description implies it should be used after obtaining a task outcome, but does not contrast with other neurogenesis tools or specify prerequisites.
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 declares the tool is read-only, which is a key behavioral trait. It also explains the current and future state (portal vs. API) and lists the data elements generated. Without annotations, this provides adequate transparency, though output format is not fully detailed.
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 dense paragraph containing valuable information but lacks structure. It could be more concise and better organized (e.g., separate purpose, usage, behavioral notes).
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 no output schema, the description lists generated fields but omits output format. It explains the workflow role but does not cover parameter meanings. For a tool with zero schema description coverage, more detail is needed to be fully complete.
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 coverage is 0% (no parameter descriptions in schema). The description does not explain what purchase_id or retirement_reason are or how they affect the output. The agent must infer from context, which is 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 states the tool generates Verra-portal-ready retirement records for Verra supply, listing specific data elements (project id, serial, vintage, etc.). It differentiates from sibling tools like offsets__verify_retirement and offsets__list_credit by focusing on record generation for a specific registry.
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 in a workflow (generate then submit under Viridis account) but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons to 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?
No annotations are provided, so the description carries full responsibility. It only describes what is returned but fails to disclose behavioral traits such as idempotency, authentication requirements, rate limits, or side effects. For a read operation, it does not confirm that it is read-only or safe to call repeatedly.
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 efficiently conveys the tool's purpose and key outputs. It uses a domain context prefix and front-loads the action verb 'Return'. No redundant or unnecessary words are present.
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 of retrieving an assembly with multiple fields, the description lists the return components adequately. However, with no output schema and no annotations, it lacks details on output format, error handling, or usage examples, making it minimally sufficient but not fully complete for agent reasoning.
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 parameter 'assembly_type' has no description in the schema. The tool description does not elaborate on valid values, format, or examples. It only implies that assembly_type identifies the assembly, adding minimal meaning 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 'Return' and specifies the resource: 'one assembly's formula, required dimensions, material factors, purchase increment, sources, and material-pack lineage.' It distinguishes from sibling tools like 'list_assemblies' by focusing on a single assembly, and from 'calculate_takeoff' which computes rather than retrieves.
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 detailed information on a specific assembly but does not explicitly state when to use or when not to use. It lacks comparison to alternatives like 'list_assemblies' for enumeration or 'calculate_takeoff' for computation, leaving the agent to infer context from sibling tool names.
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 bears full responsibility for behavioral disclosure. It mentions the output attributes but fails to describe side effects, authentication needs, pagination, or any constraints. As a non-destructive list operation, the behavior is mostly implied, but the description lacks explicit 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 after a domain prefix, which is concise and front-loaded. The bracket prefix may be extraneous, but the core description is tight with 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?
For a simple list tool with no parameters and no output schema, the description covers the main returned attributes. However, it lacks mention of pagination, return format, or any filtering capabilities, leaving some gaps in completeness.
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, so no parameter explanation is needed. The description adds value by listing the attributes returned (version, digest, etc.), which compensates for the lack of an output schema. 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 purpose: listing bundled material packs with specific attributes like version, digest, coverage, shapes, etc. The verb 'List' and resource 'material pack' are precise, and it distinguishes from sibling tools like 'get_material_pack' and 'list_assemblies'.
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 does not provide any guidance on when to use this tool versus alternatives such as 'get_material_pack' or 'list_assemblies'. No usage context, prerequisites, 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.
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 implies a read-only operation ('return'), which is adequate, but does not explicitly state that it is non-destructive or whether it requires authentication. For a simple query tool with no parameters, this is minimally acceptable.
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 short (two sentences) and front-loads the context ('verdigraph — verifiable cognition...') before stating the core action. The first sentence in brackets provides useful branding but could be shortened. Overall, it is concise and easy to parse.
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 simplicity of the tool (zero parameters, no output schema), the description adequately covers what the tool does. It explains it returns capabilities and input contract. No further detail is strictly necessary, though mentioning the agent name more explicitly could help.
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, so schema coverage is 100% trivially. The description does not need to elaborate on parameters. The baseline score of 4 applies because the description adds no parameter info, but none is needed.
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 'Return capabilities and input contract', clearly indicating the tool's function as a descriptive introspection endpoint. It specifies the resource (verdigraph agent) and action (return), but does not differentiate from numerous other describe_agent siblings, missing a chance to clarify what makes this agent's capabilities distinct.
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 the many other describe_agent tools (e.g., neurogenesis__describe_agent, notary__describe_agent). The description lacks context for selecting the appropriate agent descriptor, which is critical given the large sibling group.
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 idempotency, URL constraints, and the fee_miner parameter's purpose. However, it omits auth requirements, rate limits, side effects, and details about the registration process. More transparency is needed 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing essential information in a single paragraph without redundancy. It could benefit from a clearer structure, but it is not overly verbose.
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, no output schema, no annotations), the description is incomplete. It lacks parameter details beyond fee_minor, does not describe the return value format, and omits prerequisites or error conditions. An agent would likely need additional information 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 0%, so the description must explain parameters. It only describes fee_minor and hints at URL constraints. Parameters like provider, description, and payment_ref are not explained, leaving gaps. This is insufficient for an agent to fill all parameters correctly.
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 registers a third-party MCP server under Viridis Verified, specifies constraints (https, public FQDN only), mentions the return of a content-addressed service_id, and notes idempotency on (url, provider). This effectively distinguishes it from sibling tools like verified__call_verified or verified__list_services.
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 registering a server, but provides no explicit guidance on when to use versus not use alternatives, nor any conditions or prerequisites. Given the many sibling tools, additional context would help an agent choose correctly.
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. It reveals the action is to file a dispute and opens an evidence window, but does not disclose side effects (e.g., whether it modifies escrow state), authorization needs, rate limits, or return behavior. Minimal 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 sentences with no fluff, front-loading the purpose. Every phrase adds value; the prefix '[arbitration — deterministic dispute rulings]' provides additional context without 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?
Given no output schema, the description should hint at return values or errors; it does not. It mentions 'opens the evidence window' but lacks prerequisites (e.g., escrow must exist), error conditions, or sequencing. Adequate but incomplete for a 4-parameter required 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 0%, so the description must compensate. It adds meaning for 'amount_minor' (cents) and implies distinctness for 'claimant' and 'respondent', but provides no details for 'escrow_id'. This partial coverage is helpful but insufficient to fully compensate for the lack of 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 'File a dispute over an escrow' with a specific verb and resource, and adds 'Opens the evidence window' for context. It distinguishes itself from sibling tools, none of which involve arbitration or dispute filing.
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?
Provides some usage constraints ('Parties must be distinct; amount is in minor currency units'), but no explicit guidance on when to use vs alternatives, prerequisites, or when not to use. Context is clear but lacks 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?
No annotations provided, so description must cover behavioral traits. Discloses irreversibility and immediate effect. However, missing details like authorization requirements or 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?
Extremely concise: two short sentences. Bracket prefix gives context. No unnecessary words.
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 no output schema and no annotations, description lacks important context: what a covenant is, how to obtain covenant_id, return value. Not sufficient for agent to confidently invoke.
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%, but description provides no information about the required 'covenant_id' or optional 'reason' parameter. Agent has no guidance on what values to provide.
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 clearly states the action: revoke a covenant immediately and terminally. The bracket context 'deny-by-default authority leases' adds domain context. Distinguishes from sibling tools like grant_covenant and check_act.
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?
Describes the effect and consequence (all subsequent checks deny), implying when to use (when permanent revocation is needed). Does not explicitly state when not to use, but the action is specific enough.
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 correctly implies a read-only lookup operation ('resolve'), but does not explicitly state that it is non-destructive, what happens on failure, or any authentication requirements. The description is minimal but 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 extremely concise, consisting of a single sentence that front-loads the core purpose. Every word is informative, 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 description covers the basic purpose and parameter usage, but given the absence of an output schema, annotations, and required parameters, additional details would be helpful—such as required parameter combinations, error behavior, and return format. The tool is not fully self-contained for an agent unfamiliar with the 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?
The description adds meaning beyond the schema's plain property titles by explaining that bridge_did can be used alternatively to the chain_id+token_id pair. However, it does not specify that the combination is required or whether they are mutually exclusive. With 0% schema coverage, the description partially compensates.
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 ('resolve'), the resource ('imported ERC-8004 registration'), and the two methods of identification ('by bridge DID or by (chain_id, token_id)'). It distinguishes itself from sibling tools like erc8004__import_registration and identity__resolve_agent through specificity to ERC-8004.
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 (e.g., identity__resolve_agent), nor are there prerequisites or restrictions mentioned. The description implies usage for resolving imported registrations but does not state when not to use it or when to prefer a sibling.
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 burden. It discloses the output fields (pack version, regions, etc.) and implies a read-only operation. However, it does not mention permissions, rate limits, or any side effects, but given the simplicity (no parameters), the description 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 extremely concise: two short sentences. The first provides context (ghg-ledger purpose), the second lists what the tool returns. No wasted words, front-loaded with key 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 no output schema and no parameters, the description is fairly complete. It lists all the fields that will be returned. It could be improved by noting that it returns a list (implied by 'list'), but overall it provides sufficient information.
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 schema coverage is 100% trivially. According to guidelines, baseline is 4. The description does not need to add parameter info.
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 that the tool lists factor packs and specifies the fields (version/digest, regions, years, etc.). However, it does not explicitly differentiate from the sibling tool 'ghg-ledger__get_factor_pack' which likely retrieves a single pack, though the 'list' vs 'get' distinction is implicit.
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 'get_factor_pack'. No when-not or context for usage is given, leaving the agent to infer based on 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?
No annotations are provided, so the description carries the full burden. It states 'FREE' but does not explicitly confirm read-only behavior, discuss side effects, authentication needs, or rate limits. While it implies a safe query, it lacks the transparency required for a mutation-free 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 concise with two clear sentences. The prefix is somewhat promotional but still informative. The core message is front-loaded and contains essential details without 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?
Given the tool's simplicity, the description covers the output (greenest path and gCO2e saved) but omits parameter details and prerequisites. It does not fully compensate for the missing output schema and nested object complexity, leaving some gaps.
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?
With schema description coverage at 0%, the description must compensate, but it adds negligible parameter insight. It mentions 'workload' without defining its structure or contents, and 'allowed_backends' is not explained. This leaves the agent to guess at valid input values.
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: 'rank compute backends by carbon for this workload' returning 'the greenest eligible path and the gCO2e saved per call'. It distinguishes from siblings by specifying 'Carbon only (GR6)' and suggests pairing with 'route_task for quality-floor routing', effectively differentiating it as a carbon-only ranking tool.
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 explicit guidance: use this tool for carbon-aware ranking, and pair it with neurogenesis__route_task for quality-floor routing. It implies when not to use (quality concerns) and offers a clear alternative, making the usage context unambiguous.
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. It mentions 'simulated flags' and implies read-only retrieval, but does not explain what happens if the job is not completed or the job_id is invalid. It lacks detail on side effects or authentication needs.
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 efficiently packs key information, including the context prefix and a list of returned items. It is front-loaded with the core action and resource, though the list makes it slightly long.
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 lack of an output schema, the description lists major return components (plan, hires, reviews, etc.) but does not cover pagination, size limits, or error conditions. It provides a decent overview but lacks depth for complex usage.
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%, so the description should explain the 'job_id' parameter. However, it only lists parameter names without adding meaning like format, purpose, or constraints. The description adds no value beyond the schema's bare existence.
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 ('Return') and the resource ('full content-addressed lineage of a completed job'), listing specific components like plan, hires, reviews, etc. It distinguishes from sibling tools like 'hive__job_status' and 'hive__verify_audit' by specifying the detailed audit output.
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 for completed jobs but does not explicitly state when to use this versus alternatives like 'hive__job_status' for status or 'hive__verify_audit' for verification. No exclusions or prerequisites 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 carries the full burden. It discloses idempotency (update), the return type, and that capabilities must be non-empty lowercase. However, it omits critical behavioral traits like authorization requirements, error conditions (e.g., invalid agent_id), or side effects. It adds some value beyond the schema but remains 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 extremely concise, packing the purpose, return, and a key parameter detail into two short sentences. It is front-loaded with context in brackets and contains no redundant information. Every sentence 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?
Given 7 parameters, no output schema, and no annotations, the description should provide more context. It covers the core purpose and capabilities but fails to explain the role of other parameters (name, pubkey, etc.) or the behavior when updating an existing identity (e.g., merge semantics). This leaves significant gaps for the agent.
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%, meaning the description must compensate. It only describes the 'capabilities' parameter (non-empty lowercase tags). The other 6 parameters (name, pubkey, pricing, agent_id, endpoint, reputation_hint) are not explained, leaving the agent to infer from defaults and names. This is insufficient for a 7-parameter tool.
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 ('Register or idempotently update') and the resource ('agent identity'). It also mentions the return type (deterministic content-addressed DID) and a key parameter (capabilities). The bracketed prefix '[identity — verifiable agent identity + capability discovery]' provides context and distinguishes it from sibling tools like identity__resolve_agent.
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 this tool is for registering or updating an agent identity, and that capabilities enable discoverability. However, it does not explicitly state when not to use it (e.g., when the agent already exists, or preferring resolve_agent or discover_agents). No alternatives are mentioned, so the guidance is present but not 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?
No annotations are provided, so description carries full burden. It discloses a read-like operation that returns public registration, but lacks details on error handling, authorization needs, or rate limits. 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?
Single sentence with clear category prefix. No wasted words, but lacks structured sections for different aspects.
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 2 params, no output schema, and no annotations, the description is minimally adequate. It explains the primary function but could detail what 'full public registration' includes and any constraints (e.g., DID format). Siblings exist but not differentiated.
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%. Description adds that either 'agent_id' or 'DID' can be used for resolution, which is helpful, but does not clarify requiredness, format, or behavior when both provided. Minimal value beyond 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?
Description uses specific verb 'resolve' and resource 'identity', and specifies the resolution methods (by agent_id or DID). It distinguishes from siblings like register_agent and discover_agents by focusing on getting full public registration.
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?
Description implies usage context (when you have an agent_id or DID and need public registration) but provides no explicit guidance on when to use vs alternatives like describe_agent, nor any exclusions or prerequisites.
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 provided, so description carries the burden. It discloses that est_accrued_minor is an estimate and that the data is bucketed per recorded_at. However, it does not describe response size, pagination, idempotency, or whether the operation is read-only. More detail on output format and potential latency would help.
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?
Description is concise with three sentences, front-loading the core functionality and key differentiation. No redundant information. Could be improved by structuring parameter descriptions, but it is efficient and readable.
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 8 parameters, no output schema, and no annotations, the description is moderately complete. It explains the high-level purpose and some parameters, but lacks details on time range, meter_id filter, and output format. An agent might struggle with exact usage without additional inferred 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 coverage is 0%, so description must explain all parameters. It covers bucket (day/hour), and mentions breakdowns by consumer_class, channel, provider. However, it fails to explain since, until, meter_id, include_test. The time range is implied but not explicitly described, and the purpose of include_test is absent.
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 clearly states the tool retrieves usage time series bucketed by recorded_at, grouped by provider, with breakdowns by consumer_class/channel/provider. It distinguishes from usage_summary by noting est_accrued_minor is an estimate and authoritative billing stays with usage_summary.
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?
Provides some guidance by stating it's a real time-series primitive independent of meter creation times, and that est_accrued_minor is not authoritative. However, lacks explicit when-to-use versus alternatives like usage_summary or sla_report, and no mention of prerequisites or context for filtering.
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 states the functional purpose and lists enum values for two parameters. It does not mention side effects, destructive potential, rate limits, auth requirements, or return format. This is insufficient for a tool with multiple parameters.
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 short and front-loaded with the main purpose. The enum lists are efficiently presented. Some redundancy (e.g., repeating 'narrative-engine' scope) could be trimmed, but overall it is concise and well-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?
Given the tool has 5 parameters, nested objects (agent_output), no output schema, and no annotations, the description is incomplete. It does not explain the agent_output format, the role of key_message and payment_ref, or what the tool returns. An agent would lack enough context to use it 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 has 0% description coverage, and the description adds meaning for two parameters (audience_type and format_type) by listing their allowed values. However, it does not explain agent_output (object), key_message, or payment_ref. This is partial documentation; a more complete description would cover all 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's purpose: translating raw ecological/agent data into a decision-maker-ready narrative. The specific verb 'translate' and resource 'raw ecological/agent data' make it unambiguous. Among sibling tools, no other tool performs narrative generation, so it is well-distinguished.
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 usage when a narrative needs to be generated for decision-makers, but it does not provide when-not-to-use or alternative tools. Since there are no sibling narrative tools, the lack of exclusions is acceptable, but more context on prerequisites or conditions would be helpful.
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 convey behavioral traits. It only states what the tool does and returns, but omits side effects, permissions, rate limits, or failure 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 includes a bracketed prefix that adds context but could be more concise. The parameter list is front-loaded, but the overall length is reasonable.
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 of creating a developmental agent and the lack of output schema, the description covers input structure and return value. However, it lacks details on validation, error conditions, or the meaning of 'evaluation-driven growth', leaving gaps.
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 is minimal (single object with additionalProperties), so the description compensates by listing expected fields (agent_name, purpose, initial_nodes, fitness_metrics, etc.) and constraints like 'unique, >=1'. This adds significant 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 states that the tool creates a developmental agent from a digital genome, listing required and optional fields. It distinguishes from siblings like delete_agent and describe_agent by focusing on 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 usage for creating an agent but does not explicitly state when to use it vs. alternatives like delete or describe. No exclusions or alternative suggestions 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?
No annotations are provided, and the description only states what is returned (ancestry, descendants, generation number). It does not disclose read-only behavior, authorization requirements, or any side effects, leaving the agent to assume it is a query without confirmation.
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, efficient sentence that immediately conveys the tool's purpose. It uses brackets for context and contains no extraneous 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 lineage query tool with no output schema, the description adequately specifies the key return values (ancestry, descendants, generation number). However, it lacks details on output structure (e.g., list vs tree, nesting).
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 elaborate on the agent_id parameter beyond the schema's title. It offers no guidance on format, source, or constraints, failing to compensate for the schema's minimal info.
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 'Full ancestry and descendants of an agent, plus its generation number,' which precisely defines the tool's function. It distinguishes from siblings like provenance__describe_agent (basic info) and provenance__recall (recall action).
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 lineage queries but provides no explicit guidance on when to use this tool vs alternatives. No when-not or alternative tool names are mentioned.
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 explains the verification process: recompute and compare identifiers, returning valid=true only if all match. This discloses deterministic recomputation behavior, though side effects (none expected) and auth needs are absent.
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 has a verbose brand tagline in brackets, then a functional sentence. It is two sentences but wastes words on branding. Overall adequate but not optimally 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 parameters and no output schema, the description lacks details on return structure (beyond valid boolean), error handling, and the VB3 reference is jargon. It is incomplete for an agent 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter explanations. It mentions 'content', 'brain_id', 'content_hash' indirectly but does not map to schema fields or explain 'format' default. The description adds no value over the empty 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 verifies a cognition claim by recomputing a brain from content and comparing against claimed identifiers. The verb 'Machine-check' and specific resource 'brain' with comparison logic distinguishes it from siblings like 'verdigraph__build_brain'.
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 verification use (after building a brain), but does not explicitly state when to use vs alternatives or provide exclusions. The sibling context makes the differentiation clear, so it's nearly explicit.
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 provided, so description carries full burden. It does not disclose what happens after submission (e.g., immutability, confirmation, or state changes). Mentions evidence kinds and weights but lacks behavioral details 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?
Very concise single sentence with essential information: domain prefix, action, condition, allowed values, and access restriction. No unnecessary 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?
Moderate completeness for a simple action: covers when, what, and who. Missing parameter details for case_id, party, and content, and lacks behavioral effects or return value. Adequate but not thorough.
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%, so description must compensate. Only 'kind' is explained with values and weights; 'case_id', 'party', and 'content' are not described. Party is implied to be a named party but format unspecified. Insufficient for 4 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?
Description clearly states verb (Submit), resource (evidence), condition (while case open), and domain context. Distinguishes from siblings like file_case and rule by specifying it's for evidence submission in open cases.
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: when to use (while case open) and who can submit (only named parties). Lacks explicit mention of when not to use or alternatives, but the context is sufficient 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the record is 'immutable', which is a key behavioral trait. However, it does not disclose what happens for invalid IDs, required permissions, or rate limits. With no annotations, it carries the full burden but provides minimal 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 no redundancy. It front-loads the namespace and immediately states the purpose. 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?
For a simple fetch operation with one parameter and no output schema, the description is mostly complete. It states the return is a single immutable record, though it does not detail error scenarios or record 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 0%, so the description must compensate. It mentions 'by inventory_id' but does not explain the format or source of the ID. This adds some meaning but is minimal given the single parameter.
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 'Fetch', the resource 'immutable inventory record', and the identifier 'by inventory_id'. It differentiates from sibling tools like 'list_inventories' which lists all 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?
No explicit guidance on when to use this tool vs. alternatives (e.g., list_inventories). The description only implies usage when you have an inventory_id, but lacks explicit when/ when-not instructions.
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 full burden. It discloses key behaviors: deterministic (idempotent), cited, no fabrication, gaps remain explicit. This provides good transparency, though it could mention whether the tool is read-only or has side effects. The deterministic hint is particularly valuable.
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 with a contextual prefix in brackets. It is concise and front-loaded, but the structure could be improved by separating parameter details or usage notes.
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 (5 params, nested objects, no output schema, no annotations), the description is incomplete. It does not explain the framework parameter options, the structure of company_facts, the role of payment_ref, or the output format. Only the core action and two inputs are described, leaving major 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 coverage is 0% (no descriptions in schema), so the description must compensate. It covers only 2 of 5 parameters (company_facts, ghg_result) and omits framework, options, payment_ref. The description adds meaning for those two but leaves significant gaps, which is insufficient for a 5-parameter tool.
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 'Compile' and the resource 'deterministic, cited compliance disclosure draft', along with the inputs (company facts, optional GHG result) and key constraints (no fabrication, gaps explicit). It distinguishes this tool from siblings like list_frameworks and verify_result by focusing on the compilation action.
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 company facts and optionally a GHG-ledger result, but does not explicitly state when to use this vs. alternatives like list_frameworks or verify_result, nor when not to use it. Basic context is provided, but lacking exclusion or 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?
No annotations exist, so the description carries the burden. It discloses the return value (datapoints, mappings, sources, lineage) and implies low risk (read operation). However, it doesn't mention idempotency, rate limits, or error conditions like missing framework. Minimal behavioral context beyond safety.
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 packed with key details: domain, frameworks, action (return), and return content. Front-loaded with domain and parentheses. No redundant words. Highly efficient.
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 retrieval tool with one parameter and no output schema, the description adequately covers what the tool returns and its scope. However, it lacks details on error handling, required credentials, and how the returned data is structured. Still sufficient for basic use.
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 only parameter 'framework' has 0% schema description coverage. The description adds context by referring to 'one bundled framework', suggesting the parameter is a framework identifier. However, it does not specify valid values, format (e.g., string enum), or how to discover available frameworks. The addition is marginal.
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 purpose: returning a bundled framework's required datapoints, mappings, sources, and lineage. It includes the domain (disclosure-compiler) and mentions specific frameworks (ESRS E1/SEC/IFRS S2/TNFD). 'One bundled framework' distinguishes it from listing tools like list_frameworks.
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 vs alternatives. While the description implies it is for retrieving details of a specific framework, it doesn't mention when to use other disclosure-compiler tools (e.g., compile_disclosure, list_frameworks). No when-not-to-use 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; description only mentions basic listing and filtering. Lacks details on pagination, sorting, default behavior, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the prefix tag adds some clutter but the core description is clear 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?
For a simple list tool with one optional parameter, description covers main functionality. Missing details on pagination, result set limits, or return format, but overall adequate.
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 has 0% description coverage, but description lists the parameter and enumerates possible state values (OPEN, FUNDED, RELEASED, REFUNDED, DISPUTED), adding meaning beyond the schema's raw string type.
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 states 'List escrows' with optional state filter, and lists all possible state values. Distinguishes from sibling escrow mutation 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?
Implies use when you need to list escrows, but no explicit when-to-use, when-not-to-use, or comparison with siblings like escrow__escrow_status.
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?
Without annotations, the description carries the burden of behavioral disclosure. It adequately states that the identity disappears from discovery (terminal) and the record is retained for auditability, indicating irreversibility and audit trail. However, it does not cover permission requirements or other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, but includes a group label prefix that may not be necessary. It efficiently conveys the core action and effect without extra 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?
Given the tool is a mutation (revoke) with no annotations or output schema, and parameters lack schema descriptions, the description should provide more details such as valid parameter values, expected behavior, error scenarios, or confirmations. The current 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description adds no additional meaning to the parameters (did and agent_id). It does not explain how to use them, their roles, or differences, leaving the agent to infer from names alone.
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 'Revoke an identity' with specific behavioral outcomes: disappears from discovery but record retained for auditability. This distinguishes it from siblings like register, resolve, discover, list, and describe.
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 revoking an identity but does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention prerequisites, when-not-to-use, or which parameter (did vs agent_id) to choose.
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 full burden. It indicates the operation requires verification and affects the 'book', but fails to disclose potential side effects, reversibility, authorization requirements, or what happens to existing credits. The disclosed behavioral traits are limited to parameter requirements.
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 at two sentences, front-loading the purpose. Each sentence adds value: the first defines the action, the second provides critical usage guidance. No wasted words, though the leading bracket text could be integrated more naturally.
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 10 parameters, no output schema, and no annotations, the description covers the essential required parameter and a key optional scenario. However, it lacks details on return values, side effects, and explanations for several parameters, so completeness is moderate.
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 description explains the meaning of verification_ref (a D-Score/land-verification attestation) and the Verra-related parameters (vcs_project_id, serial_number, vintage, methodology, registry). However, it does not explain other parameters like issuer, mass_g, project_id, price_minor_per_kg, leaving gaps. With 0% schema description coverage, the description partially compensates.
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 ('List') and resource ('conservation credit on the book'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'offsets__book' or 'offsets__register_project', though the tool name provides some distinction.
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 guidance on when to use this tool: when listing a verified credit, with verification_ref required. It also explains the special case for trading on Verra network, detailing the additional parameters needed. However, it does not mention when NOT to use it or suggest alternative 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 provided. The description implies a read-only audit function but does not explicitly state side effects or permissions. It discloses the recomputation and confirmation actions but not whether it modifies 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?
One concise sentence with a context-setting prefix. No wasted words, front-loaded 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?
Adequately describes purpose and public auditability, but lacks expected output/return value information. No output schema or return type hinted, which could be important for a verification 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?
No parameters (schema coverage 100%). Baseline 4 per rubric. The description adds context about what is computed (hash chain, conservation) but no parameter-specific info needed.
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 recomputes the disbursement certificate hash chain and confirms whole-book conservation, using specific verbs and resources. It distinguishes from other offsets tools by focusing on verification of disbursement, but does not explicitly differentiate from similar verify tools like offsets__verify_certificate or offsets__verify_retirement.
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?
Implied usage as an audit tool ('Any party can audit disbursements'), but no explicit guidance on when to use this vs alternatives like offsets__certify_disbursement or offsets__disbursement_schedule. Lacks exclusion criteria or context.
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 must convey behavioral traits. 'Fetch' implies a read-only operation, but the description does not explicitly state idempotency, safety, or permissions. For a simple retrieval, this is adequate but not 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 sentence with a category prefix, containing no wasted words. Every part is relevant and front-loaded with the category context.
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 no output schema and no annotations, the description is insufficient. It does not describe the return format, error behavior (e.g., artifact not found), or any additional behavioral context, leaving the agent underinformed for a 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that artifact_id identifies the artifact to fetch, adding 'registered' implying the artifact must exist. However, it lacks details on format, constraints, or source of the ID.
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 (Fetch) and the resource (one registered artifact) with the key identifier (artifact_id). The prefix 'provenance — genesis certificates, lineage, recalls' provides context, and it distinguishes from sibling tools like 'provenance__list_artifacts' and 'provenance__register_artifact'.
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 an artifact_id and need a single artifact, but it does not explicitly mention when to use this tool versus alternatives like 'provenance__list_artifacts' for multiple artifacts or 'provenance__verify_artifact' for verification. No exclusions or prerequisites are stated.
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 provided, so description carries full burden. Indicates a read operation, but omits details like error handling, permission requirements, or what 'recall/quarantine status' specifically includes. Adequate but minimal.
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, front-loaded with domain context, concise with 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?
Given one required parameter, no output schema, and siblings, the description is minimally viable but lacks details on output structure and retrieval conditions, which could confuse agents unfamiliar with the domain.
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 description adds no extra meaning beyond the parameter name 'agent_id'. The phrase 'an agent's genesis certificate' implies the agent_id, but does not clarify format, constraints, or required relationships.
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 explicitly states it fetches an agent's genesis certificate and recall/quarantine status, using specific verb 'fetch' and resource. Clearly distinguishes from sibling tools like get_artifact, recall, or verify_certificate.
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?
Implies usage when needing genesis certificate or recall status, but lacks explicit when-not or alternative guidance. For example, no distinction from verify_certificate or lineage.
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 provided, so description must self-disclose. It reports quarantining all transitive descendants and flagging the agent. However, lacks details on reversibility, required permissions, or whether the source agent is also quarantined (only 'flagged').
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 zero waste: first covers action, second covers output. Information is front-loaded 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?
Reports output (which agents quarantined) but no output schema. Lacks error handling, format of the report, or prerequisite conditions. Adequate but not fully complete for a recall operation.
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 has 0% description coverage. Description explains agent_id implicitly but does not describe the 'reason' parameter at all, leaving the agent without guidance on its purpose or constraints.
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 clearly states the action ('Recall an agent') and its effects ('flags it and quarantines every transitive descendant'), distinguishing it from sibling tools like provenance__lineage which likely only show lineage without recall.
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?
Implied usage: use when needing to recall an agent and quarantine descendants. No explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned despite many sibling tools that could serve similar but different purposes.
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 describes the tool as a listing operation, implying read-only behavior, but does not explicitly state safety, permissions, or return format. This is adequate for a simple list but lacks depth (e.g., no mention of side effects or access limitations).
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 but includes a bracketed prefix ('[quantity-takeoff — auditable construction material takeoffs (locked waste + purchase rounding)]') that adds domain context but is not directly about the tool's function. This slightly detracts from conciseness and front-loads extraneous 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 no parameters, no output schema, and no annotations, the description provides comprehensive details on what is listed (assemblies, dimensions, formulas, waste defaults, material-pack digest). It covers the tool's output adequately for a list operation, though pagination or access restrictions are omitted.
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 schema description coverage is 100%. The description adds no parameter info because none is needed. Per guidelines, baseline 4 applies for zero 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 lists supported assemblies along with required dimensions, formulas, waste defaults, and the current material-pack digest. The verb 'List' and specific resources make the purpose unambiguous, distinguishing it from sibling tools like 'get_assembly' (singular) and 'list_material_pack' (separate resource).
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 lacks any guidance on when to use this tool versus alternatives. No mention of prerequisites, context for selection, or exclusions. For instance, it does not suggest using 'quantity-takeoff__get_assembly' for a specific assembly or indicate that this tool provides a digest of material packs.
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?
Mentions idempotency and the funding_ref linking payment, but doesn't describe side effects, state changes, or required permissions. No annotations to supplement.
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 purpose, no superfluous 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?
Adequate for a simple activation tool with idempotency and one notable parameter. Lacks mention of return value or state prerequisites, but overall 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?
Provides context for funding_ref (links payment transaction), but bond_id is undocumented. Schema has 0% description coverage, so description partially compensates.
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 states the action (activate), the resource (bond), and idempotency. Distinguishes from sibling tools like surety__post_bond and surety__release_bond.
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, no prerequisites mentioned (e.g., bond must be posted). Does not specify conditions for activation.
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 bears full responsibility for behavioral disclosure. It reveals that results are auditable, that missing facts return indeterminate, that this is not tax advice, and includes pricing and payment details. It does not describe side effects or authorization needs, but for a computation tool this is sufficient. The description adds value beyond the structured fields.
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 tool's purpose and credit types. It is relatively concise given the amount of necessary information (credits, facts constraint, pricing, payment). The pricing and payment instructions could be considered extraneous but are directly relevant for tool usage. There is minimal waste.
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 no output schema and no annotations, the description covers the core functionality, credit types, facts requirements, and pricing. However, it lacks a description of the return value (what does an 'auditable scenario' look like?) and does not direct users to related tools (e.g., list_rule_packs) for preparation. Completeness 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 0%, so the description must compensate. It explains the 'credit' parameter's allowed values (45Q/45V/45Y/48E/45X) and that 'facts' must be credit-specific. However, it does not elaborate on the structure of facts or describe the 'payment_ref' parameter beyond payment instructions. It adds significant meaning but leaves gaps for the facts parameter.
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 'calculate' and the resource 'tax credit scenario', and specifies the supported credit types (45Q, 45V, 45Y, 48E, 45X). It distinguishes itself from sibling tools like list_rule_packs and verify_tax_credit_result by indicating this is the main calculation function. However, explicit differentiation from siblings is not provided, so a 4 is appropriate.
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 implicit guidance: facts must contain credit-specific eligibility facts, and missing facts return indeterminate. It does not explicitly state when to use this tool versus alternatives (e.g., when to use get_rule_pack first), nor does it provide exclusions. The guidance is present but not comprehensive.
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 exist, and the description does not disclose behavioral traits beyond the obvious list operation. It omits information about safety, idempotency, authentication requirements, or return format, which would be needed for full 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 concise sentence with no fluff. It front-loads the namespace context and then states the purpose 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 absence of an output schema and annotations, the description is incomplete. It does not clarify what the 'rule-pack digest' contains or the structure of the returned data, leaving the agent to guess.
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 baseline is 4 per guidelines. The description adds no parameter information, but none is needed since the input schema is empty.
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 supported credits and the current bundled rule-pack digest, with a verb (List) and specific resources. It distinguishes from siblings like get_rule_pack and calculate_tax_credit by implying it returns an overview list.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description only states what the tool does, leaving the agent to infer usage context from the tool name and 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 full burden. It discloses that the ruling is deterministic, exactly-once, and idempotent (re-ruling returns existing ruling). It also explains the inputs (evidence weights, trust scores) and output (escrow instruction). However, it does not mention prerequisites or error conditions.
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 efficiently packs key information (purpose, inputs, behavior, idempotency). It is front-loaded with a clarifying tag. Could be slightly restructured for readability, but overall concise.
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 no output schema and no annotations, the description covers the core behavior but omits prerequisites (e.g., trust scores must be set, evidence submitted). For a complex domain like arbitration, this missing context lowers completeness.
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 only mentions case_id in passing without describing its format, source, or constraints. The agent is left without guidance on how to obtain or validate the required parameter.
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 that the tool issues a deterministic ruling, allocates disputed amounts based on evidence weights and trust scores, and emits an escrow instruction. It distinguishes itself from sibling tools like arbitration__file_case and arbitration__submit_evidence by focusing on the ruling action.
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 that the tool should be used after evidence and trust scores are set, but it does not explicitly state when to use it versus alternatives like arbitration__verify_ruling. No exclusions or alternative tool names are 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, description must convey behavior. It states 'Totals are exact sums of ledger entries' indicating read-only aggregation. However, it does not mention authentication needs, rate limits, or potential 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?
Two sentences, front-loaded with purpose and metrics, no redundancy. Every sentence adds value.
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 1 parameter, no output schema, and no annotations, the description covers the return metrics and data source. Lacks clarity on time scope or ledger context, but is mostly sufficient for a simple aggregation tool.
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 has 0% description coverage for parameters; the description only vaguely mentions 'for an agent' without explaining agent_id format or source. More information is needed for correct usage.
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 clearly states it aggregates footprint for an agent, listing specific metrics (J, kWh, gCO2e, cost, mean Landauer efficiency). It distinguishes from sibling tools like list_entries by focusing on sums rather than individual entries.
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?
No explicit when-to-use or when-not-to-use guidance given. The description implies it is for obtaining aggregate footprint data, but does not contrast with alternatives like ghg-ledger__calculate_inventory or compute-ledger__describe_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?
No annotations provided, so description bears full burden. It discloses append-only behavior and idempotency on inventory_id. However, it does not describe response format, authentication needs, rate limits, or effects on other data. Partial 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?
Three sentences with no wasted words: contextual header, main action, and key constraints. Front-loaded with the core purpose. Efficient and readable.
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 complexity (7 parameters, no output schema, no annotations), the description covers the basis but lacks clarity on what 'content_digest' refers to, expected output, and prerequisites (e.g., factor pack version). Adequate but with notable 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 0%. The description adds meaning for mass_g (exact integer grams), content_digest, and factor_pack_digest (bare lowercase SHA-256 hex), and notes idempotency on inventory_id. Other parameters (agent_id, source_ids, factor_pack_version) are not described. Partially compensates for low 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 'Record an audited GHG inventory' and specifies the resource (GHG inventory) and location ('separate append-only chain'). It distinguishes from sibling read tools like compute-ledger__get_inventory and compute-ledger__list_inventories, emphasizing write and idempotency.
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 for recording inventories but does not explicitly state when to use versus alternatives like compute-ledger__get_inventory or compute-ledger__record_work. No guidance on prerequisites or contexts where this tool should be avoided.
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 bears full burden. It discloses that the output is unsigned and content-addressed, and that the user must sign it themselves. It does not specify side effects or read-only status, but the description provides adequate transparency about the tool's non-finalizing nature.
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 a bracketed prefix that adds context. It is concise and front-loaded, with no unnecessary 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?
The description covers the core purpose but lacks explanation of parameters and return format. Given the absence of an output schema and annotations, the agent may have difficulty using the tool correctly without additional parameter details.
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 does not explain the parameters chain_id and token_id beyond their names. The description adds no meaning to these required fields, forcing the agent to guess their 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 verb (Export), the resource (agent's current trust score), and the output format (UNSIGNED ERC-8004 Validation Registry-shaped payload). It distinguishes this tool from siblings like import_registration, bind_identity, and verify_attestation, which handle different aspects of the ERC-8004 workflow.
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 to prepare an unsigned attestation for the user's own signing, but it does not explicitly state when to use it versus alternatives like erc8004__verify_attestation. No prerequisites 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 provided, so description bears full burden. It states it lists 'all' imported registrations, implying no filtering. However, it does not disclose any behavioral traits like authentication, rate limits, or output 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?
Very concise. Two short sentences with no fluff. The prefix '[erc8004 — ...]' is slightly redundant but does not detract. 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?
Given zero parameters and no output schema, the description is minimally adequate. It does not mention pagination, sorting, or any limitations, but for a simple list tool it is sufficient.
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 has zero parameters (100% coverage). Description adds meaning by specifying scope ('all imported'), which is useful. Baseline for 0 params is 4; description provides no param details but clarifies intent.
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 clearly states 'List all imported ERC-8004 registrations.' Verb 'List' and resource 'imported ERC-8004 registrations' are specific. Distinguishes from sibling tools like erc8004__import_registration (import) and erc8004__resolve_agent (resolve).
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?
No explicit guidance on when to use or when not to use this tool versus alternatives. For a simple list with no parameters, it's adequate but lacks any mention of alternatives or context.
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 provided, so description must disclose behavior. It states the state transition and that an arbiter subsequently resolves it. This gives useful context but lacks details on idempotency, side effects, or error conditions.
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?
Description is two sentences: first states core purpose, second adds future process. The bracket label '[escrow — trustless escrow & settlement (exactly-once)]' may be extraneous but not damaging. It is fairly concise.
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 state transition tool with two parameters and no output schema, the description covers the purpose, condition (funded), and aftermath (arbiter). However, it lacks parameter details and error/requirement information, so 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions for parameters). The description does not explain 'escrow_id' or 'reason' beyond naming them. It mentions 'Move a FUNDED escrow' but does not clarify parameter semantics or format. Parameter names are somewhat self-documenting, but the description fails to add any meaningful detail.
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 clearly states 'Move a FUNDED escrow to DISPUTED', specifying the exact verb ('Move') and resource ('escrow'), and the state transition (funded to disputed). This distinguishes it from sibling tools like escrow__fund_escrow, escrow__release_escrow, etc.
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?
Implicitly indicates use when escrow is funded ('Move a FUNDED escrow'). However, no explicit when-not or alternative guidance is given. The mention of an arbiter later provides context but not comparative usage.
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 explains what the tool returns (joules, gCO2e, assumptions, etc.) and lists possible input fields. Since no annotations are provided, it carries the full burden, but it does not explicitly state that it is read-only or any side effects. It adds some behavioral context but is not exhaustive.
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 run-on sentence that mixes purpose, parameter details, and return values. While it front-loads the purpose, the inline parameter list reduces readability. More structured formatting would improve 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 flexible input schema and no output schema, the description adequately explains input expectations and return values, including assumptions and Landauer context. It is sufficient for 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (object with additionalProperties), so the description's enumeration of possible fields (backend_id, total_tokens, etc.) provides crucial semantics that the schema lacks. This fully compensates for the 0% 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 that the tool provides a free energy/carbon footprint quote for an agent workload. It specifies the action (quote) and the resource (footprint of workload), distinguishing it from sibling tools like listing certificates.
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 (e.g., neurogenesis__compute_efficiency_report). The description does not mention any circumstances 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the operation is a read (list) but does not mention safety, authentication requirements, scope (global vs. context-specific), pagination, or side effects. The lack of any behavioral context is a gap.
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 short but includes a bracketed prefix that may be extraneous. It is mostly concise, though the prefix adds minor clutter. Every sentence serves a 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 parameters and a simple list operation, the description provides sufficient information about what is returned (meters with event/invoice counts). It is reasonably complete for a straightforward list tool, though absence of an output schema limits detail.
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 (baseline 4). The description does not add parameter information because none exist, so it meets the baseline expectation.
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') and resource ('all meters') and mentions what is returned ('event/invoice counts'). It clearly distinguishes from sibling tools like metering__create_meter (create) and metering__usage_summary (summarize).
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 obtaining a list of meters with counts, but provides no explicit guidance on when to use this tool versus alternatives (e.g., metering__list_events, metering__usage_summary) 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?
Discloses idempotency and billing guarantee, but no annotations exist; the description does not cover error behavior, permissions, or other side effects beyond what is 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 context tag, no fluff. Every word 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?
With 5 parameters, 3 required, no output schema, and low schema coverage, the description leaves significant gaps in parameter meaning and return expectations.
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%; description adds meaning for event_id (idempotency key) and outcome ('ok'/'error' feeds SLA), but does not explain quantity, metadata, or meter_id.
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 starts with a clear context tag and states the verb 'Record' and resource 'usage event', distinguishing it from sibling tools like metering__list_events and metering__usage_summary.
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?
Explicitly states idempotency on event_id, indicating safe retry and no double billing. Provides context for outcome parameter feeding SLA report, but does not mention when not to use 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?
No annotations exist, so the description must disclose behavioral traits. It only mentions the output (credit book with totals) but lacks details on read-only nature, side effects, or prerequisites.
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 short and to the point, though the bracketed prefix is somewhat extraneous. It conveys the core purpose efficiently.
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 explains the output (full credit book with totals). No output schema exists, but the description suffices.
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?
No parameters exist (0 params), so baseline is 4. The description adds no parameter info, but none is needed.
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 provides 'the full credit book with per-credit and book-wide mass conservation totals,' distinguishing it from sibling tools like offsets__list_credit or offsets__net_position.
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 the full credit book but provides no explicit guidance on when to use it vs. alternatives or when not to use it.
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 the full burden. It only states the basic operation and epoch filter, with no mention of behavioral traits such as side effects, pagination, ordering, or result format. Given the lack of annotations, more detail is expected.
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 purpose. It includes a helpful prefix for context and no extraneous information. Every word adds value.
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 simplicity (one optional parameter, no output schema), the description is minimally adequate. However, it omits details about the return format or any pagination/limiting behavior, which would be helpful for an agent invoking this 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 only parameter 'epoch' has no description in the schema (0% coverage), but the tool description adds meaningful context: 'optionally by epoch (0 = founding cohort)'. This clarifies the meaning of epoch values beyond the raw schema type.
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 'List', the resource 'genesis records', and the optional filter by epoch. The prefix '[provenance — genesis certificates, lineage, recalls]' provides domain context and differentiates from sibling tools such as provenance__list_artifacts or provenance__get_certificate.
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 listing genesis records with an optional epoch filter, but does not explicitly state when to use this tool versus alternatives like provenance__list_artifacts. No exclusions or context for when not to use it are 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?
The description discloses idempotency and no genesis index consumption, adding value beyond the schema. But it omits other behavioral aspects like error handling, side effects, or prerequisite conditions, relying fully on the description due to absent 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?
Two sentences with no waste. The domain tag brackets provide context upfront, and every clause adds value. Ideal length for a tool description.
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?
Lacks information on return values, error conditions, or prerequisites. Given no output schema and complex parameters, the description should cover what the response looks like or any state changes beyond 'register'. Leaves the agent guessing.
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?
With 0% schema description coverage, the description only clarifies 'parent_hashes' (may be registered artifacts or external content roots) and artifact_id (idempotent). The other 4 parameters (relation, artifact_hash, metadata_digest, producer_agent_id) receive no explanation, leaving significant gaps.
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 'Register a content-addressed artifact in a separate provenance DAG' with a specific verb ('Register') and resource, distinguishing it from sibling tools like provenance__register_genesis or read-only 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 implies usage for non-genesis artifacts by noting 'does not consume a genesis index' and mentions idempotency on artifact_id. However, it lacks explicit when-not-to-use guidance or comparison with related 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 provided. Description indicates it lists cases and supports optional filtering, but does not disclose read-only nature, pagination, rate limits, or scope of data returned. Gains some transparency from prefix 'deterministic dispute rulings' but insufficient for full behavioral understanding.
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?
Extremely concise: one sentence with a brief prefix. All information is front-loaded and no unnecessary words.
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?
Missing output description, no mention of return format, ordering, pagination, or any additional details about the list. Given no output schema, the description should at least hint at what the response contains.
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 has 0% description coverage. Description compensates well by naming the parameter 'state' and listing allowed values (FILED|EVIDENCE_OPEN|RULED), which adds critical context missing from 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 'List' and the resource 'cases', and the prefix provides domain context. It distinguishes from siblings like arbitration__get_case (single case) and arbitration__file_case (create).
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?
Implied usage: use for listing cases with optional filtering. No explicit guidance on when or when not to use this tool compared to siblings like arbitration__get_case or arbitration__file_case. Lack of alternative recommendations.
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 provided, and the description does not disclose authorization needs, side effects, or return behavior beyond recomputation.
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 with a clear prefix, effectively communicating the tool's function without unnecessary 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?
Although simple, the description omits output format or return value; for a verification tool with no output schema, more completeness would be beneficial.
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 description adds meaning to the 'result_json' parameter by specifying it as the prior result in JSON, which is absent from the schema with 0% 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 recomputes specific elements (audit hash, notary payload, etc.) for disclosure drafts, distinguishing it from siblings like compile_disclosure.
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?
It implies usage after compilation by saying 'pass the prior result,' but lacks explicit when-to-use or when-not-to-use guidance compared to 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 explicitly mentions 'idempotent' and 'exactly-once' semantics, which are important behavioral traits beyond the basic action. However, it does not cover error cases (e.g., what if escrow is not OPEN) or side effects beyond funding. Given no annotations, the description adds good value but could be more thorough.
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 extremely concise: two sentences that front-load the core purpose and then add key detail about the parameter. Every sentence earns its place; no wasted words.
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 no annotations or output schema, the description should explain more about return values, expected behavior (e.g., success/failure indicators), and prerequisites. It omits what happens if the escrow is not in OPEN state or if the payment_ref is malformed. The agent may be left with insufficient guidance 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 description explains that payment_ref 'links the payment-rail transaction', adding meaning beyond the schema. However, escrow_id is not elaborated. With 0% schema description coverage, the description partially compensates but leaves one parameter without additional context.
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: 'Mark an OPEN escrow as FUNDED' with idempotent semantics. It specifies the resource (escrow), the state transition (OPEN to FUNDED), and links to payment_ref. This distinguishes it clearly from sibling tools like open_escrow, release_escrow, etc.
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?
While the description implies this tool is used after opening an escrow and before release/refund, it does not explicitly state when to use it versus alternatives. No 'when not to use' or list of alternative tools is provided, leaving the agent to infer from context.
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 discloses behavioral traits: forces reviewer!=author, synthesizes only reviewed content, settles escrows exactly-once, returns audit hash and telemetry, and pricing details. This provides rich context for decision-making.
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 (two sentences) and front-loads the core action. However, it uses jargon that may reduce clarity for some agents, and the density of information could be better structured with bullet points.
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 (11 params, no output schema, no annotations), the description lacks essential detail: no parameter explanations, vague return description (audit hash and telemetry), and no mention of error conditions or prerequisites. The description is insufficient for a complex orchestration tool.
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 explanation for any of the 11 parameters (e.g., problem, budget_minor, subtasks). The required parameters are not defined, leaving the agent without guidance on how to fill them correctly.
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 opens and runs a hive job, hires solvers, forces cross-review, synthesizes only reviewed content, settles escrows, and returns audit hash and telemetry. It distinguishes itself from sibling hive tools (e.g., hive__job_status, hive__audit_job) by being the main solve 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 implies usage by explaining the orchestration process and mentions pricing (3 free/day, then $5). However, it does not explicitly state when not to use it or compare to alternatives like hive__audit_job, 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 provided; description lacks behavioral details such as read-only nature, potential side effects, or pagination. Only states the action without extra context.
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?
Description is concise with two sentences. The prefix '[notary — commit-reveal verifiable delivery proofs]' is slightly unnecessary but not harmful. Front-loaded with key info.
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?
Adequate for a simple list tool with one optional parameter, but lacks details on return format, pagination, or ordering. No output schema to compensate.
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 description adds meaning to the 'state' parameter by listing the three possible values (PENDING, REVEALED, EXPIRED) beyond the schema's generic anyOf string|null.
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 'List' and the resource 'commitments', and distinguishes from sibling tools like commit, reveal, verify by focusing on listing with optional state filter.
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 clear: use when you need to list commitments with optional state filter. No explicit exclusions or alternatives, but the context from sibling tools makes it adequate.
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?
Describes verification but does not disclose side-effects, idempotency, or permissions. No annotations provided to compensate. Adds some context about delivery proofs.
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?
One concise sentence with context prefix. Slightly redundant 'commit-reveal' but efficient overall.
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?
Covers core functionality and parameter roles but lacks return value description, error cases, and prerequisites. Schema description coverage is 0% so description compensates partially.
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?
Explains commitment_id as the commitment to verify and content_digest as optional check. Adds meaning beyond schema fields which have no 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?
Clearly states it verifies a revealed commitment and optionally checks against a content digest. Distinguishes from sibling notary tools like commit, reveal, status.
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?
Suggests use after a reveal and for checking content, but lacks explicit guidance on when not to use or alternatives. Siblings include commitment_status which might overlap.
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 provided, so description carries full burden. 'Return' implies a safe, read-only operation with no side effects. It does not disclose any potential costs or rate limits, but nothing contradictory.
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?
Single sentence with a prefix tag. It is front-loaded and concise, though the tag adds minor clutter. One sentence is sufficient for the simple 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?
Minimal but acceptable for a describe tool with no parameters and no output schema. Could benefit from mentioning what 'capabilities' or 'status' entails, e.g., if it returns human-readable text or structured 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?
No parameters exist (schema coverage 100%, 0 params). Baseline of 4 for zero-parameter tools applies; no additional parameter description needed.
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 clearly states the tool returns 'ProtoGen capabilities and current CAD environment status'. Verb 'Return' with specific resource distinguishes it from sibling tools like protogen__create_cad_workspace or protogen__health.
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?
No explicit guidance on when to use this tool vs alternatives. The purpose is clear (introspection), but it does not mention when not to use it or suggest alternatives like protogen__health for health checks.
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?
Despite no annotations, the description discloses return structure (net, waste-adjusted, purchase quantities) and caveats (planning estimate, not guaranteed). It also hints at locked waste and purchase rounding behaviors.
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 very concise: two sentences plus a parenthetical prefix. It front-loads the purpose and avoids unnecessary detail, making it efficient for an AI agent to parse.
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 covers purpose, input type, output, and limitations, but lacks parameter-level details (e.g., what items array should contain, options usage) and error handling, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that items come from geometry or measurement payloads, but no details on options or payment_ref. This partial coverage leaves significant gaps.
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 ('Calculate') and resource ('auditable material takeoff') and distinguishes from sibling tools like get_assembly or verify_result by specifying the input source (explicit geometry or measurement payload).
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 the tool (when you have geometry or measurement payload for takeoff) but does not provide explicit guidance on when not to use it or alternatives among siblings.
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 explains the scaling process and optional distortion check via height, but does not disclose the output format, side effects (e.g., does it save results?), or any authentication/rate limit requirements. The description is moderately 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 concise, starting with a bracketed context tag, then a one-line summary, followed by a clear list of arguments. Every sentence is informative and there is no 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?
Given no output schema, the description should specify return values. It does not mention what the tool returns (scaled objects?). Also, it omits prerequisites like ensuring a credit card is visible in the photo, which is especially relevant given the sibling `credit_card_photo_instructions` tool. The description is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by detailing each parameter. It explains `image_id`, `credit_card_pixel_width`, `objects` (including required and optional sub-fields), and `credit_card_pixel_height` with its distortion-check purpose. This adds significant meaning beyond the bare 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 ('Scale') and resource ('object pixel dimensions using a standard CR80 credit card reference'). It distinguishes itself from sibling tools like `smartscale__credit_card_photo_instructions` by focusing on measurement scaling rather than photo capture instructions.
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. While it implies use after obtaining a photo with a credit card, it does not reference the sibling tool `smartscale__credit_card_photo_instructions` as a prerequisite or suggest when scaling is 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?
With no annotations, the description carries full burden. It discloses that the tool never charges a card and fails closed under certain conditions, but lacks details on authentication, rate limits, or side effects. Moderate 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 efficient sentences, front-loading the purpose with a bracketed context note. No 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 tool with 2 parameters and no output schema, the description covers purpose and failure conditions but omits parameter semantics and return value details.
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 does not explain the two required parameters (plan_id, account_ref) or their valid values. It mentions plan conditions but not parameter specifics.
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 that the tool prepares a Stripe-hosted subscription Checkout URL, using specific verbs and resource identification. It also distinguishes itself from siblings by noting it never charges a card and listing failure conditions.
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 implicitly tells when to use (to prepare a checkout URL without charging) and lists failure conditions (draft plans, missing approval, etc.), but it does not explicitly compare to alternatives or give when-not-to-use 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 full burden. It discloses that claims pay out only after an arbitration ruling and references slash_bond, but does not mention permissions, reversibility, side effects, or post-filing behavior. Moderate 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 concise sentence with a context prefix. Every word adds value; no redundancy. Front-loaded with important context.
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 captures core logic (claim filing with arbitration dependency) but lacks parameter details, output behavior (no output schema), and full process explanation. Partially complete for a moderate-complexity tool.
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%, yet the description provides no explanations for any of the four parameters (bond_id, claimant, amount_minor, reason). The agent must infer from names, which is insufficient for correct 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 verb 'file a claim' against a specific resource 'active bond'. It distinguishes from sibling tool slash_bond by noting the arbitration-ruling dependency and includes context 'bonding + ruling-gated slashing'.
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 says when to use (file a claim against an active bond) and implies when not to (use slash_bond for enforcement after ruling). It provides clear context but lacks explicit 'when not to' or alternatives beyond the reference.
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?
Since no annotations are provided, the description carries full burden. It discloses key behaviors: ruling is required, no double payout, payout cap against bond balance (over-claims exhaust bond). It does not explicitly state if the operation is destructive or reversible, but the name and context imply mutation.
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 purpose and context (surety bonding + slashing). It then adds conditions concisely. At 2 sentences plus a prefix, it is efficient but could be slightly more concise by removing the bracketed prefix.
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 provided. The description does not explain return value, success/error states, or side effects. For a 5-parameter tool, more completeness is needed to guide the AI on what to expect after 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?
With 0% schema coverage, the description must explain parameters. It mentions 'case id + content hash' mapping to ruling_case_id and ruling_hash, and implicitly bond_id and claim_id. However, it does not explain the 'upheld' boolean parameter (default true) or how 'payout caps' relates to input.
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 explicitly states 'Execute an arbitration ruling against a claim' with specific verb 'execute' and resources 'ruling' and 'claim'. It distinguishes from sibling tools like 'file_claim' and 'release_bond' by mentioning 'ruling-gated slashing' and 'payout caps'.
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 states prerequisites: 'Requires the ruling's case id + content hash' and conditions: 'no ruling, no slash; a given ruling pays at most once'. It implies when to use (after arbitration ruling) but does not explicitly mention when not to use or alternative 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?
Despite no annotations, the description discloses key behaviors: decay-weighted computation, output range [0,1] and tier, and neutral prior for unknown agents. It does not state whether the tool is read-only or requires permissions, but it adds value beyond the input 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 concise sentences with a brief prefix. Every sentence adds value: the first states purpose, the second clarifies edge-case behavior. No unnecessary 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the main output and special behavior (neutral prior). However, it lacks details on possible error cases, tier values, and the agent_id parameter, making it slightly 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?
Schema coverage is 0% with no description for the single parameter 'agent_id'. The description does not compensate by explaining the parameter format, source, or constraints, leaving ambiguity for the agent.
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 'Get an agent's decay-weighted trust score in [0,1] and tier,' specifying the action (Get), resource (trust score and tier), and scope. It distinguishes from sibling tools like trust__attest, trust__record_outcome, etc., which handle different trust operations.
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 that unknown agents receive a neutral 0.5 prior, clarifying the tool's behavior for new agents. While it does not explicitly list when to avoid this tool, the context of sibling tools and the distinct purpose imply appropriate usage.
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 behavioral disclosure burden. It indicates the tool performs detection without side effects, but does not detail output format or behavior on invalid content. This is minimal but not contradictory.
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 short, with two sentences. The first sentence is a lengthy prefix with branding, which could be trimmed. However, the core information is front-loaded and the description 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?
For a simple detection tool with one parameter and no output schema, the description covers the purpose and basic usage. It lacks explicit mention of return value or error handling, but is adequate given 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?
With 0% schema description coverage, the description adds meaning by explaining that 'content' is an agent-file string and listing valid formats. However, it does not specify the format of the input or how to provide it (e.g., raw text vs. path).
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 that the tool detects the format of agent-file content, listing four specific formats. It is a specific verb+resource combination that distinguishes it from siblings like verdigraph__build_brain and verdigraph__verify_brain.
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 says 'before building', implying use as a precursor to build_brain. While it doesn't mention when not to use or provide alternatives, this is adequate context for a simple detection 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?
No annotations provided, so description must convey behavioral traits. It states the tool lists services and counters, which implies a read-only operation, but does not explicitly mention idempotency, side effects, or any constraints.
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?
Single sentence with a bracketed prefix providing context. Efficient, but the prefix could be considered extraneous.
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 should explain what the list contains or how counters work. It only says 'call/fee counters', which is vague. Adequate but not 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?
No parameters, so the description does not need to detail them. Baseline 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?
Description clearly states the tool lists registered services with call/fee counters. The verb 'list' and resource 'registered services' are specific. Among sibling tools like verified__register_service and verified__service_stats, this tool is distinct.
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?
No explicit guidance on when to use this tool versus alternatives like verified__service_stats. Usage is implied but 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?
No annotations provided, so description carries full burden. Discloses trustless, exactly-once semantics, fee frozen at open, and retry-safety. Lacks mention of permission requirements or side effects beyond state change.
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?
Concise, front-loaded, and well-structured. Contains all essential information without filler. Could be slightly more organized but effective.
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 8 parameters, no output schema, and no annotations, the description is incomplete. Explains retry-safety and fee computation but omits many parameter details and error conditions.
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%; only amount_minor and open_ref are explained in text. Other 6 parameters (payee, payer, terms, fee_bps, currency, deadline) lack any description. Inadequate compensation.
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 opens an escrow between payer and payee, differentiating it from sibling escrow tools like fund, release, refund, dispute. It specifies the verb 'open' and resource 'escrow', and adds retry-safety details.
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 on when to use: for opening escrows. Mentions retry-safety with open_ref and duplicate behavior. However, does not explicitly state when not to use or compare to alternatives like direct settlement.
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 provided, so the description carries the burden. It discloses outputs (per-line gas/CO2e, rollups, etc.), states it's deterministic, and mentions pricing and payment flow. However, it does not explicitly address side effects, authentication, or idempotency, but overall provides substantial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph starting with domain and function, which is effective. However, the lengthy list of output names (e.g., 'per-line gas/CO2e results, Scope 1/2/3 and category rollups...') could be shortened without losing clarity. Overall, it is 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?
Given the tool's complexity (GHG calculation), the description covers purpose, outputs, and cost well. However, it lacks details on input parameter structure (e.g., format of activities), prerequisites (e.g., need for factor packs), and does not clarify the payment_ref parameter beyond mentioning payment methods. These gaps reduce completeness.
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 adds minimal parameter detail. It mentions 'explicit activity records' hinting at the activities parameter, and payment info for payment_ref, but lacks structure, types, or examples for activities and options. The description fails to compensate for the lacking 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 purpose: 'Calculate an auditable GHG inventory from explicit activity records.' It specifies the domain (GHG inventories Scope 1/2/3 dual Scope 2) and lists key outputs, distinguishing it from sibling tools like classify_activity or verify_result.
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 usage: when you have explicit activity records and need a GHG inventory. It notes 'This is calculation, not advice,' but does not explicitly state when not to use or provide alternative tools. Context is clear but lacks 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?
No annotations are provided, so the description carries the full burden. It mentions the tool is deterministic and returns specific data, but does not state behavior on missing region/year (e.g., error or empty result) or confirm read-only nature. Some additional behavioral context would be beneficial.
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: a bracketed domain context and a concise statement of return value and constraint. Every sentence adds value, and it is front-loaded with the domain information. 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?
Given no output schema, the description enumerates return components (factors, GWP, conversions, sources, pack SHA), which is helpful. It covers the main purpose but could elaborate on structure (e.g., factors per scope/gas) and error handling for missing packs. Overall, fairly complete for a retrieval tool.
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 0% description coverage for both parameters (region and year). The description adds only the word 'exact' to constrain them, but fails to specify expected region format (e.g., ISO code) or allowed year range. This is insufficient given the zero schema coverage; more parameter guidance is needed.
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 returns factors, GWP values, conversions, sources, and pack SHA for a specific region/year. The bracketed context sets the domain, and the explicit 'No nearest-region or nearest-year substitution' distinguishes it from sibling tools that may perform fuzzy matching.
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 says 'No nearest-region or nearest-year substitution', telling the agent when not to use this tool. This provides clear negative guidance. However, it does not explicitly mention alternative tools like list_factor_packs for browsing available packs, which would improve positive 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 provided, so description carries full burden. It discloses the read-only list action but lacks details on authorization, pagination, or performance constraints.
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?
Single sentence with a domain prefix; slightly verbose but overall efficient and 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?
For a 0-param list tool, description explains return fields adequately. Lacks details on ordering or limits, but sufficient for typical use.
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?
No parameters exist; description adds value by listing output fields (id, kind, price, capabilities), which goes beyond the empty 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?
Description clearly states the action 'List' and resource 'registered solver pool', and specifies returned fields (id, kind, price, capabilities). Distinguishes from sibling tools which are different operations.
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?
Implied usage for retrieving solver pool, but no explicit guidance on when to use or not use this tool, nor mention of 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?
Discloses key behaviors: filters to active agents, AND semantic matching, ordering by match count then reputation. Lacks details on pagination or output format, but given no annotations, this 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?
Single concise sentence with domain prefix and clear functional description. 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?
Covers purpose and key behavioral traits, but lacks output format description and limit semantics. For a simple tool with no output schema, additional context 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?
Explains capabilities parameter's matching logic, but does not mention the limit parameter. With 0% schema description coverage, the description partially compensates but misses covering the limit parameter.
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 clearly states the tool finds ACTIVE agents matching requested capabilities with AND semantics and deterministic ordering. Distinguishes well from sibling identity tools like resolve_agent and list_registrations.
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?
Implied usage for capability-based discovery, but no explicit when-not or alternatives. Agent might benefit from guidance vs other identity discovery methods.
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 tool is read-only and describes the internal logic (splitting proceeds, withholding default). It also surfaces the pending registration case. This is good transparency for a preview tool, though it could mention if there are any rate limits or idempotency.
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, using a single paragraph with minimal wasted words. It front-loads context in brackets and clearly states the action. However, it could be slightly more structured by separating the parameter description from the logic, but overall 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?
Given no output schema, the description should explain the return format. It describes the internal calculation logic, but does not specify what the output contains (e.g., list of splits, amounts, project names). For a preview tool, this context is important for the agent to interpret results. The description is partially complete but lacks output specification.
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, meaning no description for the 'project_id' parameter. The description only implies its use by mentioning 'for each verified restoration project', but does not explain the parameter's format, default behavior (empty string), or how to specify multiple projects. This leaves the agent guessing about how to invoke the tool correctly.
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: an automated disbursement preview that splits proceeds for verified restoration projects. It specifies the action (preview), the resource (disbursement schedule), and the context (offsets clearinghouse). It also distinguishes itself from sibling tools like offsets__certify_disbursement by noting it's a read-only preview and mentions a separate category for pending registration projects.
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 tool for previewing disbursements before certification/verification. It mentions read-only nature and notes that funded-but-unregistered projects are handled separately, implying when to use the tool. However, it does not explicitly state alternatives or when not to use it, which would earn 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?
The description explicitly labels the tool as read-only, which is the primary behavioral trait. It also lists the returned data fields (purchases, mass_g, cost_minor), adding transparency beyond the schema. However, it does not mention error conditions or rate limits, but since there are no annotations, this is acceptable.
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 extremely concise: two sentences covering purpose, data returned, and optional filtering. Every word adds value, and the most important 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?
For a tool with two parameters and no output schema, the description explains the core functionality and output fields. However, it lacks details on the output format or how this tool fits into the offsets workflow, which would aid 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 description adds meaning to the 'since' parameter by specifying it is an optional ISO-8601 timestamp. However, it does not explain the 'buyer' parameter format or constraints, which is a gap given the schema has 0% description 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?
Description clearly states the tool provides a read-only cash-settlement summary for a buyer, listing exact sums of retirements. It distinguishes itself from other offsets tools by specifying that it returns aggregated settlement data, not individual purchases or lists.
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 mentions it is read-only and optionally filterable by ISO-8601 timestamp, but does not explicitly state when to use this tool versus other offsets tools like 'offsets__net_position' or 'offsets__book'. No prerequisites or alternatives are 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 transparency burden. It discloses what the tool returns (prices, coverage, SHA, flags, notice) but does not mention read-only nature, auth requirements, rate limits, or pagination 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 sentence that packs all relevant information. While dense, it is efficient and front-loaded with a context label. It could be slightly clearer with separation, but remains concise.
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 no output schema, the description enumerates key return fields (prices, coverage, SHA-256, readiness flags, notice), making it fairly complete for a list operation. It covers the essential aspects of the catalog.
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 (baseline 4). The description does not need to add parameter context, and it correctly omits any unnecessary 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 clearly states the tool lists a versioned monthly-seat catalog with specific details (prices, coverage, SHA-256, readiness flags, confirmation notice). It uses a specific verb 'list' and resource 'catalog', distinguishing it from siblings like get_plan for single plans.
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?
No explicit when or when-not to use is provided. The description implies it is the comprehensive catalog listing, but does not guide the agent to prefer it over get_plan or other subscription tools for specific scenarios.
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 provided, so description carries full burden. It discloses the release action and the constraint of no open claims. Lacks details on side effects (e.g., what happens to the bond after release) but the core behavior is 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?
Single sentence with a parenthetical context, no fluff. Front-loaded with the action and condition. Every word serves a 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?
Given no output schema, the description should clarify return value or confirmation. It does not. However, the tool is simple (one param) and the description covers the essential constraints, so it's minimally complete but missing post-release 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?
Schema coverage is 0%, so description must compensate for parameter meaning. The single parameter 'bond_id' is not explained at all in the description; no guidance on format or how to obtain it. The description adds no value 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 ('Release the remaining stake') and the condition ('after the coverage window elapses'). It differentiates from sibling tools like filing a claim or slashing a bond by focusing on release. However, it assumes domain knowledge of terms like 'stake' and 'principal'.
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?
Explicitly states when to use ('after coverage window elapses') and when not ('refused while any claim is still open'). Provides clear preconditions without needing to consult other 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, the description carries the burden. It discloses key behaviors: idempotency (reuse of call_id returns cached result, downstream not double-called), tamper-evident receipt creation, and failure handling (receipted evidence). However, it does not detail side effects like the receipt chain's growth or potential authorization requirements, leaving some gaps.
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 relatively concise, with the core purpose in the first sentence and idempotency/failure details following. It avoids redundancy but could be more structured (e.g., bullet points for parameters). Still, it is front-loaded 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?
Given the complexity (6 params, no output schema, idempotency, receipt chain), the description explains the intent and idempotency but lacks parameter details, return value format, and prerequisites (e.g., registration via register_service). It is adequate for a basic understanding but incomplete for autonomous invocation without further 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 0%, so the description must explain parameters. It names some parameters indirectly (service_id, call_id) but does not describe tool, arguments, timeout_s, or payment_ref. Without this, agents may misuse or omit important parameters. The description adds minimal value beyond the schema field names.
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: relaying a tool call to a registered MCP service and notarizing the exchange. It specifies the verb (relay, notarize) and the resource (tamper-evident receipt chain). The distinctive 'verified' branding and mention of idempotent receipts differentiate it from siblings like get_receipt or register_service.
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 useful context, including idempotency on call_id (replay safety) and that failures are recorded as receipts. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like registering the service first. The guidance is good but not comprehensive.
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 burden and discloses critical behaviors: deny-by-default, idempotency (safe to retry), and audit trail logging. No contradictions.
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 extremely concise: two sentences plus key traits, front-loading the purpose. Every sentence adds value with no 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?
Despite the concise and transparent description, it lacks return value details (no output schema) and does not explain what the tool returns or example usage. Adequate but 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?
Schema has 0% parameter description coverage, and the description does not explain any of the four parameters (covenant_id, act_id, scope, amount_minor). The agent gains no guidance on parameter meaning or usage.
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 clearly states the verb ('Check') and resource ('proposed act against a covenant'), and adds distinctive details like 'deny-by-default' and 'idempotent on act_id', which differentiates it from sibling tools like grant or revoke.
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 this tool is used for checking acts before recording, but does not explicitly state when to use it versus alternatives like grant or revoke, nor does it provide when-not conditions.
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 provided, so description carries full burden. It lists what is returned and mentions 'deterministic', implying idempotency. However, it does not disclose side effects, authentication needs, or rate limits. For a describe tool, this is adequate but not exemplary.
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 packs substantial information: domain, deterministic nature, and return items. Every word is meaningful; no wasted space.
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 parameters and no output schema, the description provides a comprehensive list of return items (capabilities, version, digest, pricing, composition, disclaimer). It lacks output structure details but is sufficiently complete for a metadata query 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?
No parameters exist, so the description does not need to add meaning beyond the schema. Baseline 4 applies; no deduction needed.
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 returns deterministic capabilities, version, pack digest, pricing, composition, and disclaimer. The bracketed prefix specifies the domain (disclosure-compiler) and frameworks (ESRS E1/SEC/IFRS S2/TNFD), distinguishing it from other describe_agent 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?
No explicit guidance on when to use this tool vs alternatives. It is implied by the domain prefix and the fact that it describes the disclosure-compiler agent, but no when-not-to-use or exclusionary info is provided.
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 full burden. It discloses idempotent behavior (re-import updates in place) and return value (canonical record with deterministic DID). It does not mention side effects, permissions, or error conditions, but covers key behavioral traits beyond the minimal.
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 with no fluff. First sentence states purpose and parameters. Second sentence adds idempotency and return value. 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?
Given 5 parameters and no output schema, the description covers the operation, key params, idempotency, and return format. Missing details on metadata parameter and any prerequisites. Almost complete for the tool's 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 coverage is 0%, so description must compensate. It lists four required parameters (chain_id, token_id, agent_uri, owner) but does not explain their semantics (e.g., chain_id format, token_id as ERC-721). The optional metadata parameter is omitted. Adds some context but not deep 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 verb 'Import' and the resource 'ERC-8004 Identity Registry record', listing the key fields (chain_id, token_id, agentURI, owner). It distinguishes from sibling tools like erc8004__resolve_agent and erc8004__import_feedback by specifying the exact record type and operation.
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 importing/updating identity registry records and mentions idempotency, but does not explicitly state when to use this tool versus alternatives (e.g., erc8004__bind_identity, erc8004__import_feedback). No when-not or exclusion criteria are provided.
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 discloses key behavioral traits: cheapest-first matching, exactly-once idempotency on purchase_id, content-addressed certificate, per-fill costs, escrow settlement, and dry run preview without mutation. This is above average but could include more on error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the domain context, and includes all essential information without redundancy. Every sentence adds value.
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 covers the core action, matching, idempotency, return, payment, and dry run. Missing details on error conditions or prerequisites, but sufficient for a focused 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 schema has 0% description coverage, so the description must compensate. It adds meaning for mass_g, dry_run, and purchase_id, but does not clarify the 'buyer' parameter. This partial coverage is adequate but not thorough.
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 ('Retire mass_g of verified credits'), the resource (verified credits), and key behaviors (cheapest-first matching, exactly-once, returns certificate). It distinguishes from sibling offsets tools by specifying the buy/retire operation.
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 buying offsets but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned, making it reliant on agent inference.
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 discloses a read-like behavior but lacks details on error responses or side effects. It is adequate for a simple health check.
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 waste, efficiently conveying the tool's 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 the tool's simplicity (zero params, no output schema), the description is sufficiently complete for a health endpoint, though it could optionally mention response format.
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?
No parameters exist, so baseline is 4. The description adds no parameter info, but schema coverage is 100%, making additional detail unnecessary.
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 returns ProtoGen health and workspace counts. It distinguishes from sibling tools that perform CAD operations like creating or exporting designs.
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 service health but provides no explicit guidance on when to use or compare with alternatives among siblings.
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 that the tool returns aggregate data and does not expose identifiers, which is helpful. However, it does not mention authentication needs, rate limits, data freshness, or error behavior, leaving some 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 sentences with no fluff. The first sentence states what it returns, and the second clarifies constraints. Every word adds value, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is fairly complete. It specifies the output components (count, MRR, plan mix) and a key constraint (no identifiers). However, it could mention authentication requirements or data freshness for full completeness.
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 no parameters, and the description does not add parameter-specific semantics. Schema coverage is 100% trivially, so no additional param info is needed. The description does not mention optional filters that could exist, but for a zero-parameter tool, this is acceptable.
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 what the tool returns: aggregate active live-mode subscription count, MRR minor units, and plan mix. It also specifies that no account or Stripe identifiers are exposed, which distinguishes it from tools that return detailed subscription data.
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 high-level subscription metrics but does not provide explicit guidance on when to use this tool vs. siblings like 'subscriptions__usage_summary' or 'subscriptions__subscription_status'. No alternatives or exclusion criteria are mentioned.
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 declares the tool is pure (never mutates bond state), deterministic, and returns a quote_hash for verification. With no annotations provided, it provides adequate behavioral disclosure, though it omits authentication or rate limit details.
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, front-loaded with a domain tag, and packs significant information into a single sentence. It could be slightly more structured, but every sentence adds value.
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 complexity (7 parameters, no output schema, no annotations), the description covers the core logic and output (quote_hash) but lacks details on return format, error handling, and edge cases. It suffices for basic understanding but not full context.
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 description explains how attestations, successful deliveries, completed bonds, and slashes affect the quote, adding context beyond the bare parameter names. However, it does not mention the 'slashed_minor' parameter, leaving a small gap in 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 underwrites a surety bond by providing a deterministic actuarial premium quote based on counterparty track record. It distinguishes itself from siblings by being pure (read-only) and never mutating bond state.
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 getting a premium quote before posting a bond, but does not explicitly state when to use this tool versus alternatives like surety__post_bond or surety__slash_bond. No when-not-to-use conditions are 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?
No annotations exist, so the description must fully cover behavior. It describes what is returned but does not explicitly state that the operation is read-only, non-destructive, or any other behavioral traits like authentication needs or rate limits.
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 extremely concise—two short sentences or one sentence with a parenthetical. Every part adds value, and the key 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?
Given the simple nature (no parameters, no output schema), the description fully covers what the tool does. It specifies the returned items and provides necessary context about ghg-ledger.
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 schema coverage is 100%. The description need not add parameter information. Baseline for zero parameters is 4, which is appropriate as no additional detail is required.
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 'Return' and the resources 'fleet-standard capabilities, version, pack digest, and pricing.' The bracketed prefix distinguishes this tool from other describe_agent tools by scoping it to ghg-ledger.
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 does not explicitly state when to use this tool versus alternatives like other describe_agent tools. The ghg-ledger context provides implicit guidance, but no direct usage or exclusion conditions 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 discloses scope (metadata only), prerequisite (admin token), and impact (default exclusion from stats). It does not mention reversibility or error handling, but provides sufficient 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, front-loaded sentence with precise language. No wasted words; every part adds value.
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?
Covers core behavior, constraints, and side effects. Lacks mention of return value, error states, or idempotency, but given no output schema and 4 parameters, it provides adequate 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 coverage is 0%, and the description does not explain individual parameters. It implies meter_id and admin_token but does not describe note or is_test beyond basic types. The description adds no parameter 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 states the action (flag/unflag), resource (meter), and effect (exclude events from usage statistics). It distinguishes from other metering tools like create_meter or record_usage by specifying it only touches meter metadata.
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?
Explicitly mentions admin-only requirement (VIRIDIS_ADMIN_TOKEN) and what it does not affect (events, hash chain, billing), helping decide when to use. However, lacks explicit alternatives for other scenarios like excluding specific events.
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 full burden. It discloses key behaviors: determinism, logging with reasons, the hard contract preventing quality regression, and the min_quality constraint. However, it omits potential side effects, authentication needs, or rate limits.
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 reasonably concise, fitting all key points in a single paragraph. The prefix in brackets adds context, but the core message is front-loaded and efficient. Minor improvement could break into structured points.
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 has one nested object parameter and no output schema, the description covers the input structure, behavioral contract, and key constraints. It is complete enough for an agent to understand usage, though return value information is absent (not required without output 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?
The input schema has 0% description coverage with a generic object, so the description compensates by listing expected fields (id, task_type, etc.) with notation for optionality and min_quality range. This adds significant meaning beyond the schema, though individual field semantics could be more detailed.
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 explicitly states the tool's purpose: 'Choose the cheapest RELIABLE compute path for a task'. It clearly identifies the verb (choose) and resource (compute path), and the context of 'route_task' distinguishes it from sibling tools like 'neurogenesis__compute_efficiency_report' or 'neurogenesis__register_compute_profile'.
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 hard contract (NG7) that defines eligibility criteria for compute profiles, but it does not explicitly state when to use this tool versus alternatives or exclude misuse cases. The guidelines are 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: it verifies against the commitment (one bit drift fails), returns a delivery_proof string, and that late reveals expire the commitment. This gives the agent a complete picture of side effects and constraints.
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 core description is efficient in three sentences, but the leading bracketed prefix '[notary — commit-reveal verifiable delivery proofs]' adds redundant domain context that is already clear from the tool name and sibling tools.
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 covers purpose, behavior, and output, but lacks detailed parameter semantics (e.g., what format is the salt, how to obtain commitment_id). For a three-param tool with no output schema, this is adequate but has clear 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?
The input schema has 0% description coverage, and the tool description only mentions 'committed content's digest + salt', partially explaining the content_digest and salt parameters. The commitment_id parameter is not explained at all, leaving a significant gap.
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 reveals committed content (digest + salt) after handover, verifies against the commitment, and returns a delivery_proof for escrow release. It distinguishes from sibling tools like notary__commit and notary__verify by focusing on the reveal step.
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 'after handover' which indicates timing, and mentions that late reveals expire the commitment, providing a caution. However, it does not explicitly state when not to use the tool or suggest alternative 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?
No annotations are provided, so the description is the sole source. It discloses idempotency on batch_id, that only newly-accrued proceeds are certified, and that it produces a tamper-evident record. It does not mention required permissions or the exact output format, but is fairly 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?
Two dense sentences with no filler. Front-loaded with the action and context about the offsets namespace. Every sentence adds value.
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 no output schema, the description covers the tool's purpose and behavior but does not explain what the tool returns (e.g., the certified batch details). The agent may need to infer from other tools in the namespace.
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 only one parameter (batch_id) and 0% schema description coverage, the description does not elaborate on what batch_id represents or its expected format (e.g., a string ID). The agent must infer from context, which is adequate but not optimal.
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 freezes the disbursement schedule into a certified, tamper-evident batch. It uses specific verbs ('freeze', 'certify') and distinguishes from sibling tools like 'offsets__verify_disbursement' and 'offsets__disbursement_schedule'.
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 good context on when to use: for certifying a disbursement batch before CEO executes Stripe transfers. It mentions idempotency and 'never disbursed twice', but does not explicitly state when not to use or list 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?
No annotations are provided. The description accurately states 'list all registered restoration projects with their metadata,' which implies a read-only operation. However, no additional behavioral details (e.g., pagination, data freshness) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a domain prefix. Every word is necessary, and it efficiently conveys the tool's purpose. No extraneous text.
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 zero parameters and no output schema, the description fully explains what the tool does and what it returns (project metadata). No gaps remain for an agent to misinterpret the operation.
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 schema is fully covered. The description adds value by specifying the scope ('all registered restoration projects') and the content ('with their metadata'), which is meaningful beyond the empty 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 it lists all registered restoration projects with their metadata, using a specific verb and resource. It distinguishes from sibling list tools like offsets__list_credit by specifying 'restoration projects' and 'verified-credit carbon offset clearinghouse' domain context.
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?
No explicit guidance on when to use this tool versus alternatives like offsets__register_project or offsets__net_position. However, for a simple list-all operation with no parameters, the usage is self-evident from the description.
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 discloses key safety information: 'this tool never moves money'. It also indicates the URL is 'bearer-owned', implying authentication requirements. No contradictions with hypothetical 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, well-structured sentence with a bracketed context prefix, front-loading essential information without unnecessary 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?
Given the simple one-parameter input and no output schema, the description sufficiently covers the tool's return value (URL) and non-monetary nature. It does not mention error cases or detailed authentication, but for this tool that seems adequate.
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 only parameter, `account_id`, is not explained in the description. The description does not clarify what `account_id` represents or how it is used, leaving the agent to infer.
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 'Return a bearer-owned Stripe-hosted billing-portal URL', with the context prefix specifying the domain. This distinguishes it from sibling tools like subscriptions__create_checkout_link by focusing on portal access rather than checkout creation.
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 usage for enabling customer self-management of subscriptions via a portal. It notes 'the human manages or cancels there', clarifying the purpose, but does not explicitly mention when not to use it or alternatives 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 full burden. It discloses determinism ('Identical bytes always produce the identical brain_id'), output structure (brain_id, content_hash, node/edge counts, firing report, provenance), and effect of 'include_document'. No side effects or failure cases, but sufficient for a compile action.
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?
Description is efficient with 6 sentences, front-loaded with a bracketed summary. Each sentence adds value (purpose, input, output, determinism, option). Slightly verbose with 'the 9-invariant firing report' but still within reason. 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?
Given no output schema, description lists return fields (brain_id, content_hash, etc.). Parameters are well explained, including format options and include_document flag. Lacks error handling or size limits, but for a compile tool this is adequate. No gaps for expected usage.
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 0%, so description adds substantial meaning. It explains 'content' as file string, 'format' with possible values (verdigraph_genome, claude_project_export, etc.), and 'include_document' behavior. Adds value beyond schema, though format list is partial (missing enum annotation).
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 verb ('Compile') and resource ('agent file into a deterministic, content-addressed brain'), distinguishes from siblings like 'verdigraph__verify_brain' by focusing on building, and includes deterministic property, making 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 description implies this tool is for building brains from agent file content, but does not explicitly state when to use it versus alternatives like 'verdigraph__detect_format' (likely for pre-processing) or 'verdigraph__verify_brain' (post-processing). No exclusions or alternatives mentioned, only implied context.
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 must carry the full burden. It discloses the returned fields but does not mention the return format (e.g., a list), potential side effects (none expected), or any other behavioral traits. For a read-only list tool, the description is moderately 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 a single, front-loaded sentence with a domain context prefix in brackets. It is concise and contains no superfluous 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?
With no output schema, the description adequately enumerates the returned fields (framework IDs, coverage, lineage, version, digest). However, it could explicitly state that this returns a list of such items, which is implied but not 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?
There are no parameters, so schema coverage is 100% by default. The description does not add parameter information, but none is needed. Per guidelines, 0 parameters receive a baseline 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 clearly states the tool lists bundled framework IDs, coverage, source lineage, version, and digest. The verb 'list' is specific, and the resource 'frameworks' is well-defined. It distinguishes itself from siblings like get_framework (which retrieves a specific framework) and compile_disclosure (which creates a disclosure).
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 implicitly positions this as the starting point to see available frameworks before using compile_disclosure or get_framework. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.
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 full burden. It declares 'No mutation,' which is a key behavioral trait. However, it omits details like idempotency, error handling for invalid meter_id, or rate limits. For a simple report, the core behavior is sufficiently 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, front-loaded sentence with no extraneous details. It efficiently conveys purpose, outputs, and safety in a concise manner, earning 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 simplicity (one parameter, no output schema), the description covers the essential return fields (success_rate, sla_target, breach flag) and the read-only nature. It does not detail the exact output format but is sufficiently complete for an agent to understand what the tool provides.
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 single parameter 'meter_id' has no schema description. The tool description does not explicitly explain that it identifies the meter for the report, but the context of 'metering' and 'sla_report' provides implicit meaning. While it adds some value beyond the schema, it does not fully compensate for the 0% 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 produces a 'Pure SLA report' comparing success_rate to sla_target with a breach flag, and explicitly notes 'No mutation.' This distinctively identifies the tool's function among the diverse sibling tools, leaving no ambiguity.
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 checking SLA compliance and is read-only, but does not explicitly specify when to use it versus alternatives (though no direct sibling exists for SLA reporting). The 'No mutation' flag provides a clear safety guideline.
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. It discloses key behavioral traits: idempotent on purchase_id, dry_run for preview without mutation, and a guarantee of never overspending. Missing details on failure modes but sufficient for safe invocation.
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, dense paragraph that efficiently conveys purpose, constraint, use case, idempotency, and dry_run. No wasted sentences; front-loaded with core 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 moderate complexity (4 params, no output schema, no annotations), the description covers the essential interactions: budget-based purchase, idempotency, dry_run. Lacks details on error handling or return values but adequate for agent decision-making.
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 0% (no parameter descriptions), so the description must compensate. It explains budget_minor as the cost limit and dry_run as preview, but does not elaborate on buyer or purchase_id. Baseline 3 given partial 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 identifies the tool as a money-denominated offset purchase that retires the maximum cheapest-first verified mass within a budget never overspending. It distinguishes itself from generic purchase tools by focusing on budget-based retirement for currency obligations.
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 it is built for callers with a currency amount obligation, providing a clear use case. It mentions idempotency and dry_run but does not explicitly contrast with siblings like offsets__buy_offset or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully clarifies read-only nature, output details (attestation_hash, receipt fields), and method logic based on workload declaration. No contradictions.
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 paragraph but front-loads the core purpose. It packs useful detail without excessive verbosity, though it could be broken into shorter sentences for clarity.
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?
Without an output schema, the description adequately covers return values (object fields) and integrates well with sibling tools. It could mention error conditions or prerequisites but 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?
Despite 0% schema coverage, the description adds meaning by explaining offset_ref as a retirement ID and implying entry_id as a work identifier. However, entry_id format or type is not elaborated.
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 emits an x402-C carbon receipt for a recorded work entry, with specific verb and resource, distinguishing it from related tools like record_work and footprint.
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 the context (recorded work entry) and optional offset_ref for carbon neutrality. It implicitly guides when to use but lacks explicit alternatives or when-not scenarios.
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 that the tool is 'Read-only' and that the CEO handles actual payouts, confirming no side effects. Without annotations, this behavioral transparency is sufficient. It also implies it is safe to call without committing changes.
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 yet informative, with a domain prefix, functional explanation, parameter guidance, and a note on read-only nature. It is well-structured and front-loaded, though slightly verbose with the prefixed bracket, which provides useful context.
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 single optional parameter and no output schema, the description covers the key aspects: purpose, parameter usage, and behavior. It lacks explicit output format details, but the mention of specific fields (gross_proceeds_minor + retired_g) gives sufficient context for an agent to understand the return 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?
With 0% schema description coverage, the description compensates by explaining the optional project_id parameter: 'Pass a project_id for one project, else all.' This adds meaning beyond the schema's default empty string and clarifies the parameter'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 clearly states the tool is a 'Supply-side disbursement ledger' that shows how much each project has earned and is owed, with specific fields (gross_proceeds_minor + retired_g). This distinguishes it from sibling tools like offsets__buy_offset or offsets__certify_disbursement, which handle different operations.
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 usage guidance: 'Pass a project_id for one project, else all.' This tells the agent how to invoke the tool. However, it does not explicitly contrast with other tools or mention when not to use it, but the context of being read-only is 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 burden. It discloses energy/carbon calculation, Landauer floor validation, rejection of physically impossible claims, and idempotency. This is transparent, though it could mention error handling or side effects more explicitly.
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, dense paragraph of four sentences with no unnecessary words. It conveys essential information efficiently.
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 (9 parameters, physics validation, no output schema), the description covers the main behavioral aspects and parameter relationships. However, it could include more detail on return value or error scenarios.
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 description explains key parameters (power_w, duration_s, bit_ops, grid_intensity_g_per_kwh) with formulas and validation logic, compensating for the 0% schema description coverage. However, it does not cover all 9 parameters (e.g., task, temperature_k, price_minor_per_kwh), leaving some ambiguity.
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 records a unit of agent compute work, provides the calculation formula, and mentions validation against Landauer floor. It distinguishes from sibling tools by specifying the context (compute-is-carbon ledger) and the specific action (recording work).
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 (to record agent compute work) and includes details like idempotency on entry_id and validation of physical bounds. However, it does not explicitly contrast with alternative tools like compute-ledger__footprint or attest, but the unique purpose is 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?
With no annotations, the description carries full burden. It discloses the tool recomputes checks and flags tampering or stale factor lineage. No side effects mentioned, which is appropriate for a verification-only tool. No contradictions.
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 domain context. Every sentence adds value: first sets context and purpose, second gives instruction and expected outcome. 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 verification tool with one parameter and no output schema, the description sufficiently covers what the tool does and what to pass. It explains the verification behavior and flagging outcome, though an agent might wonder about the return format.
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 0%, so description must compensate. It specifies that result_json is the 'prior result object as JSON', adding essential context beyond the raw schema. While it does not detail the exact structure, it gives sufficient guidance for the single parameter.
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 recomputes audit hash and conservation checks for a prior GHG inventory, using the specific verb 'Recompute' and resource 'prior inventory's audit hash and conservation checks'. It distinguishes from siblings like ghg-ledger__calculate_inventory which creates new inventories.
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 tells the agent to pass the prior result as JSON and explains the outcome (tampering flagged). It implies usage after having a prior inventory, but does not explicitly mention when not to use it or contrast with alternatives like calculate_inventory.
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, description fully covers behavioral traits: explains how commit_hash is computed (sha256 double hash), that deadline is ISO-8601, that context links to escrow/job, and that operation is idempotent. Does not mention potential side effects (e.g., overwrites previous commit?) but for a commit tool this is sufficient.
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 sentences, no fluff. Front-loaded with purpose, then key details (hash computation, deadline, context, idempotency). 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?
Given no output schema and no annotations, the description adequately explains inputs and effect. Covers all required parameters functionally. Could mention the return value (e.g., commitment ID or status) but not critical since output is likely a simple success indicator.
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 has 0% descriptions; the description compensates by explaining commit_hash format, deadline format, context role, and idempotency via nonce. Not all parameters (e.g., committer) are detailed, but the essence is covered. Adds significant meaning beyond bare property names.
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 states the tool's purpose: 'Commit to a deliverable BEFORE handover' as part of a commit-reveal scheme. Uses specific verb 'commit' and resource 'deliverable', distinguishing it from sibling tools like reveal and commitment_status via context.
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?
Explicitly says when to use: before handover. Idempotency hint (per committer, nonce) guides safe usage. Does not list when NOT to use or explicitly name alternatives, but the commit-reveal context makes usage boundary clear.
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?
Discloses key behaviors: content-addressed certificate, monotone index, epoch 0, lineage tracking, quarantine effect, idempotency. No annotation contradiction.
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 plus a domain prefix; every sentence adds value without redundancy. Front-loaded with 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?
Adequately covers behavior and constraints for a 3-parameter tool with no output schema. Minor gap: missing artifact_hash explanation and output description.
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 0% so description must compensate. It explains agent_id and parent_id well, but does not mention artifact_hash parameter at all.
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 states the tool registers an agent's birth, issues a genesis certificate, and handles lineage. Distinguishes from sibling tools by focusing on birth/genesis.
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?
Implies when to use (for agent registration) with constraints like idempotency and quarantine on recalled parents, but no explicit alternatives or when-not-to-use 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 provided, the description carries the full burden of disclosing behavior. It explicitly states 'Read-only', indicating no destructive effects. It also describes the return values. However, it does not mention any required permissions or potential side effects beyond the read-only nature, which is a minor gap.
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 moderately concise and front-loaded with the entity name. It provides essential information in two sentences. However, it contains some jargon ('x402-C C4 check') that may not be universally understood, slightly reducing clarity.
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 moderate complexity (2 parameters, no output schema), the description provides all necessary context: purpose, parameter meanings, return values, and read-only nature. It is complete enough for an agent to use correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so effectively by explaining that purchase_id is the offset reference ('offset_ref = purchase_id') and that required_g is the minimum grams to retire. This adds meaning beyond the schema's field titles.
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: to confirm a retirement meets a minimum gram requirement. It uses specific verbs and resources ('confirm a retirement', 'retires at least required_g grams'), and distinguishes itself from siblings like offsets__verify_certificate by focusing on retirement verification with a threshold.
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?
While the description does not explicitly state when to use this tool over alternatives, the context is clear: it is used to verify that a retirement offsets a specific amount of credits, which is distinct from other verification tools that focus on certificates or records. The purpose implies a specific use case, but lacks explicit exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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/jdhart81/viridis-agent-fleet'

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