Joy Trust Network

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

Since no annotations are provided, the description carries the full burden. It does disclose that payment is released, which is a significant side effect, but it omits critical details such as irreversibility, required authorization (despite the schema hint that agent_id must be the poster), or the effect on the job's status. This is particularly important for a financially-impacting action.

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

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

The description is a single, concise sentence that front-loads the primary verb 'approve'. There is no extraneous text, redundancy, or unnecessary elaboration, making it highly efficient.

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

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

For a simple two-parameter tool, the description captures the core action and outcome well. However, it omits behavioral context such as reversibility and authorization, which is especially relevant for a payment-releasing tool. Given the lack of annotations, this gap prevents a perfect score, but the tool's low complexity makes the description mostly adequate.

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

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

The input schema already provides clear descriptions for both 'job_id' and 'agent_id', achieving 100% schema description coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'approve' and identifies the resource ('submitted work') and the outcome ('release payment'). It is clear and unambiguous, though it does not explicitly distinguish it from the sibling tool 'complete_deal', which might also involve payment release.

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

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

No guidance is provided on when to use this tool versus alternatives like 'complete_deal' or 'submit_job'. The only hint is the phrase 'submitted work', which implies it follows submission, but there is no explicit sequencing, prerequisites, or exclusions. This is insufficient for choosing among sibling tools.

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

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

With no annotations available, the description carries full responsibility for disclosing behavioral traits. It does not mention side effects, such as locking the job to prevent duplicate claims, or potential errors like claiming an already claimed job. This omission is significant 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.

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

The description is a single, brief sentence that directly conveys the core action. There is no wasted text or redundancy, making it efficiently structured.

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

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

For a simple claim operation with no output schema and no annotations, the description is under-specified. It omits important context such as what happens after claiming (e.g., exclusivity), potential error conditions, or any needed permissions, leaving the agent without sufficient information to fully anticipate the tool's behavior.

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

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

Schema description coverage is 100%, and both parameters (job_id, agent_id) are described. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The verb 'claim' and resource 'open job' clearly state the tool's function. It effectively distinguishes from sibling tools like post_job (creating a job), list_jobs (viewing), and submit_job (submitting work).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. The purpose is implied but there is no mention of prerequisites, exclusions, or recommended context.

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

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

With no annotations, the description discloses the core behavior—completing a deal and releasing payment—which is important for a high-stakes mutation. However, it omits side effects, failure conditions, reversibility, or response details, leaving notable transparency gaps.

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

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

The description is a single, front-loaded sentence with no filler words. Every part earns its place by stating the action and the consequence.

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

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

For a simple 2-parameter tool with full schema coverage, the description captures the primary purpose and the payer constraint. It does not describe return values or post-conditions, but given the low complexity and absence of an output schema, it is nearly complete.

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

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

The schema descriptions already cover both parameters (100%) with clear, meaningful descriptions such as 'Agent ID completing the deal (must be the payer)'. The tool description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Mark'), clearly identifies the resource (a deal), and states the key effect (release payment to the payee). This distinguishes it from sibling tools like create_payment_deal, list_deals, and approve_job.

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

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

The description clearly implies this is the final step in a deal's lifecycle, and the schema further constrains usage by requiring the agent to be the payer. However, it does not explicitly contrast with alternative tools such as resolve_stake or approve_job, nor state 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.

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

With no annotations, the description carries the full burden, but it only restates the action. It doesn't disclose side effects, e.g., whether the campaign is published immediately, requires permissions, or how scheduling works.

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

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

The description is a single sentence with no redundant words, making it extremely concise. It is appropriately sized in terms of length, though it lacks substantive detail.

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

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

Given a relatively complex tool with 6 parameters, enums, and no output schema or annotations, the one-sentence description is inadequate. It doesn't explain the campaign creation workflow, required fields, or expected behavior.

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

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

All 6 parameters have descriptions in the schema (100% coverage), so the schema already documents them. The tool description adds no additional parameter meaning, so baseline 3 is appropriate.

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

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

The description uses a specific verb 'create' and resource 'marketing campaign', clearly indicating the action. It distinguishes from sibling tools like list_campaigns by the verb, but adds little nuance beyond 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.

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, no prerequisites, no exclusions, and no context about scheduling or platform selection.

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

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

No annotations are present, so the description carries the transparency burden. It reveals that the payment deal uses escrow, which is a meaningful behavioral detail. However, it does not disclose side effects (e.g., funds held, when released) or what the tool returns.

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

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

A single, front-loaded sentence with a clear verb and a relevant parenthetical about escrow. Every word earns its place; there is no redundancy.

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

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

The tool is simple and its parameters are well documented in the schema. However, with no annotations and no output schema, the description should offer more guidance on when to use it versus alternatives and what to expect upon creation. The escrow mention helps but leaves gaps.

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

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

All four parameters have descriptions in the schema, so the baseline is 3. The description's 'pay another agent for work' adds context to amount_cents and description but does not provide format or syntax details beyond the schema.

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

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

The description uses a specific verb 'Create', identifies the resource as a 'payment deal', and clarifies the purpose: paying another agent for work. The mention of escrow further distinguishes it from sibling tools like create_stake and create_campaign.

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

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

Clear context is provided: use this tool to pay another agent for work. It does not explicitly mention alternatives or exclusions, but the use case is specific enough to infer when this tool would be appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the risk/return behavior by stating 'lose on failure, gain bonus on success,' which is critical for an agent to understand before invoking a staking operation. However, it doesn't mention permissions, reversibility, or any other behavioral constraints, but the core risk profile 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.

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

The description is a single, front-loaded sentence that states the purpose and key behavior without any redundant information. Every phrase earns its place, making it highly concise and well-structured.

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

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

There is a significant mismatch between the description and the schema: the description mentions a 'task' but no task identifier parameter exists in the input schema (only agent_id, ttl_hours, stake_amount, delegation_id). This would confuse an agent trying to select the correct task. Additionally, there is no output schema, so return values are undisclosed. The description is incomplete for an agent to fully understand invocation context.

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

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

The input schema provides 100% coverage with descriptions for all four parameters. The description adds minimal extra value, only reinforcing that 'stake_amount' involves JTS and that staking is tied to task outcomes. Since the schema already explains parameter meanings, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb and object: 'Create a reputation stake on a task.' It further clarifies the stakes mechanism ('stake JTS, lose on failure, gain bonus on success'), which distinguishes it from sibling tools like resolve_stake or get_stakes.

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

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

Usage context is implied rather than explicitly stated. The description indicates the tool is for creating reputation stakes, but it doesn't provide explicit guidance on when to prefer this tool over alternatives, nor does it mention any conditions or exclusions. For example, it doesn't say 'Use this when you want to commit reputation to a task or when you need to create a stake before task completion.'

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a support ticket', which adds no information beyond the tool's name. It does not mention side effects, permissions, idempotency, return value, or any post-conditions. This is a minimal disclosure gap 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.

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

The description is a single efficient sentence with no redundant words. It is front-loaded with the action and object, making it easy to scan. While it omits details, conciseness itself is good; it's not under-specified to the point of being a bare tautology.

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

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

There is no output schema, so the description should at least hint at what the tool returns (e.g., ticket ID). It doesn't. The tool is simple, but the missing return-value and behavioral context make it incomplete for an agent to use confidently. Companion tool get_ticket suggests a ticket is created, but the description doesn't confirm what response to expect.

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

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

Schema description coverage is 75% (3 of 4 params described), and priority has an enum and default that clarify its meaning. The description itself adds no parameter details, but the schema already covers most semantics. Since coverage is not >80%, the baseline isn't full, but the gap is minor and the description doesn't need to compensate heavily.

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

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

The description clearly states the action and object: 'Create a support ticket for issue tracking'. This is a specific verb+resource combination that distinguishes it from sibling tools like create_campaign or create_stake, and aligns with the name.

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

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

The description implies usage for creating tickets but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It's clear enough for the core use case but lacks any contextual direction beyond the action itself.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait that payment is not automatic and requires human browser interaction. It does not mention side effects like link expiration or permissions, but the most critical behavior is transparent.

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

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

Two concise sentences front-load the core action and immediately follow with the crucial human-completion requirement. Every word earns its place with no unnecessary detail.

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

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

For a simple two-parameter tool with no output schema, the description fully conveys purpose, return value, and a critical behavioral constraint. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already thoroughly documents agent_id and amount_cents including minimum and default. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description clearly states it creates a payment link to add funds to a wallet, using a specific verb and resource. It also clarifies the return value (a URL) and the distinguishing requirement that a human must open it in a browser.

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

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

The description provides clear usage context by stating the link must be opened in a browser by a human, implying this tool is for scenarios requiring human interaction. It does not explicitly mention alternatives or exclusions, but the constraint is apparent.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the search function, offering no details about read-only nature, return format, pagination, or behavior when the query and capability parameters are combined.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core action and scope. Every word contributes meaning; there is no fluff or repetition.

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

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

The tool has no output schema, so the description should explain what the tool returns, but it only says 'find' without specifying the result type (e.g., a list of agents). It also omits information about how limit behaves or whether capability and query are mutually exclusive. For a simple search tool, this is a clear gap.

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

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

The schema already describes query and capability, and the description reinforces their roles. The limit parameter, however, lacks any schema or description detail, leaving ambiguity about its purpose and default behavior. With 67% schema coverage, the description provides modest added value but does not fully compensate for the missing limit explanation.

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

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

The verb 'Find' combined with resource 'AI agents' clearly states the tool's purpose as a search/discovery operation. It implicitly distinguishes from the sibling 'get_agent' (which likely retrieves a specific agent) but does not explicitly note this distinction.

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

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

The description implies usage for finding agents by capability or search query, but provides no explicit guidance on when to use this tool versus alternatives like get_agent, nor does it mention any exclusions or prerequisites. The context is minimal and relies on inference.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states 'Get' which restates the tool name, adding no information about side effects, error handling, or output format. This is a 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.

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

The description is a single, six-word sentence that is direct and free of any filler. It conveys the essential information without unnecessary words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core action and input fairly well. It could mention what 'details' entail, but for a simple getter this is acceptable and matches the minimal scope.

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

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

The schema only defines 'agent_id' as a string, but the description clarifies it is used as an identifier ('by ID'). This adds meaning beyond the raw schema, compensating for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: 'Get agent details by ID' with a specific verb and resource. It does not explicitly differentiate from sibling tools like 'discover_agents' or 'get_ticket', but the subject 'agent details' is distinct enough.

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

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

The phrase 'by ID' implies this tool is for retrieving a single agent when an ID is known, contrasting with listing tools like 'discover_agents'. However, there is no explicit when-to-use or alternative guidance, leaving the context to be inferred.

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

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

No annotations are provided, so the description carries the burden of disclosure. It states what the tool returns but does not explicitly say it is read-only, whether authentication is required, or if any side effects exist. The name suggests a safe read operation, but that is not stated.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. Every word earns its place, with no wasted content.

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

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

Given no parameters and no output schema, the description gives the core purpose but leaves ambiguity about the structure of 'departments, tickets, and activity' (e.g., are these counts, lists, or summaries?). It is adequate but not exhaustive.

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

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

The tool has zero parameters, so the description need not add meaning to any schema properties. The baseline of 4 applies for tools with no parameters.

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

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

The description uses the specific verb 'Get' and identifies the resource 'organization overview' with key contents (departments, tickets, activity). It clearly distinguishes from sibling tools that target individual entities like get_agent or get_ticket.

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

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

The description implies the tool is for an org-wide overview but provides no explicit when-to-use guidance or comparisons to alternatives. No exclusions or prerequisites are mentioned, making usage context only inferred.

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

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

No annotations are provided, so the description carries the burden. The verb 'Get' implies a read-only operation, and 'complete' suggests comprehensive output, but no details on auth, rate limits, or response shape are given. This is adequate for a simple read tool 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.

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

A single, front-loaded sentence that is concise and contains no filler. Every word contributes to understanding the tool's purpose.

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

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

Given the simple one-parameter schema and no output schema, the description is minimally sufficient but lacks usage context and return format details. It does not address potential confusion with related trust tools, leaving the agent to infer.

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

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

The schema has 0% description coverage and the description does not mention agent_id or its meaning beyond what the name conveys. It adds no extra context about the parameter's role, format, or relationship to the passport.

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

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

The description uses a specific verb 'Get' with a clear resource 'behavioral passport' and states what it shows ('cross-platform trust history'), distinguishing it from siblings like get_trust_score or verify_passport.

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

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

No guidance is provided on when to use this tool vs alternatives such as get_trust_score, verify_passport, or issue_passport. The description only states what it does, not the conditions for choosing it.

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

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

With no annotations, the description carries the full burden for disclosing behavior, but it only says 'get', implying a non-destructive read. It does not mention whether the response is a list, whether it includes active/resolved/expired stakes by default, or any other behavioral characteristics such as pagination or data scoping.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core purpose efficiently without redundancy.

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

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

The tool is simple, but without an output schema, the description should explain what a 'stake' includes and what the response format looks like. The description lacks any info about return structure, possible empty results, or how the status filter behaves, leaving the agent to guess.

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

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

The schema covers agent_id with a description but leaves status entirely undocumented (only an enum). The description repeats 'for an agent' but says nothing about the status parameter, its default value, or how filtering works. With 50% schema coverage, the description fails to compensate for the undocumented parameter.

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

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

The description clearly states the action ('get') and the specific resource ('reputation stakes') with a target ('for an agent'). This distinguishes it from sibling tools like create_stake, resolve_stake, and get_trust_score, which have different purposes.

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

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 comparing with get_trust_score or viewing resolved stakes via a different tool. There are no exclusions, prerequisites, or contextual hints beyond the bare operation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves status and details, but does not disclose whether any side effects occur, whether authentication is required, or what happens on a non-existent ticket. There is no mention of read-only nature or error handling.

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

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

The description is a single, front-loaded sentence that precisely states the tool's purpose without any fluff or repetition of the schema. It is concise and every word adds value.

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

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

For a simple get-by-id tool with one parameter and no output schema, the description is minimally viable, but it lacks detail about what 'details' includes or the return format. It also does not mention error behavior. Given the low complexity, the gaps are acceptable but not ignored.

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

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

The input schema fully documents the single parameter 'ticket_id' with a description, giving 100% schema coverage. The tool description does not add any additional meaning about the parameter, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Get' with a clear resource 'support ticket' and specifies the output as 'status and details', which distinguishes it from the sibling 'create_ticket' tool. This is a clear and non-redundant statement of the tool's function.

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

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

The description gives no explicit guidance on when to use this tool or what alternatives exist. It does not mention scenarios like 'when you need to look up an existing ticket' or differentiate from 'create_ticket'. The usage is only implied by the verb 'Get'.

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

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

With no annotations, the description alone must convey behavioral traits such as read-only nature, potential side effects, or return behavior. The description only states that it gets a trust score, without confirming it is a safe read-only operation or describing error/rate-limit behavior.

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

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

The description is a single, clear sentence with no fluff. It says exactly what the tool does and front-loads the main action and object.

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

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

For a simple two-parameter getter with full schema coverage, the description adequately conveys the core function. However, absence of an output schema and annotations means the description doesn't explain return format or platform-specific behavior, leaving some gaps.

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

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

The input schema already provides full descriptions for both parameters (100% coverage), so the baseline is 3. The tool description adds no new meaning beyond reiterating that the platform is optional, which is already in the schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource (trust score for an agent) with an optional platform modifier. This distinguishes it from sibling tools like verify_trust or get_passport by focusing on retrieving a score rather than verifying or obtaining a passport.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or conditions for when to choose this over verify_trust or other getters. Usage is only implied by the name and description.

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

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

With no annotations, the description must disclose behavioral traits. It implies a read-only operation ('Get') and lists return content, but it does not explicitly state side effects, authentication requirements, or rate limits. The concise phrasing adds minimal behavioral context beyond the action itself.

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

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

The description is a single, front-loaded sentence that concisely lists the tool's outputs. Every word contributes value with no redundancy.

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

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

For a simple one-parameter get tool, the description is reasonably complete. It specifies the return categories (balance, transactions, payment actions), but lacks guidance on usage context and potential edge cases, which are minimal for this type of tool.

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

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

The schema fully describes the single parameter (agent_id) with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool's function: 'Get your wallet balance, transaction history, and available payment actions.' It names the resource (wallet) and the specific data returned, distinguishing it from sibling tools like get_agent or get_passport.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what the tool does, not the context for its use.

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

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

With no annotations, the description carries the full transparency burden. It reveals that the token is signed, portable, and offline-verifiable, but does not disclose side effects, permissions required, idempotency, or whether the operation is destructive. This is partial but not rich behavioral context.

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

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

A single, tightly worded sentence conveys the core purpose and key characteristics. No wasted words; information is front-loaded and scannable.

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

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

Despite full schema parameter descriptions, the tool has no annotations or output schema, and the description does not explain return values, failure modes, or usage context. For a state-changing issuance tool, this leaves significant gaps for an agent to invoke it confidently.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (agent_id, scope, ttl_hours). The description adds no parameter-specific meaning beyond what the schemas provide, meeting the baseline of 3.

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

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

The description uses a specific verb ('Issue') with a clear resource ('portable, signed identity passport token') and adds a distinctive qualifier ('verifiable offline'). This clearly distinguishes it from sibling tools like get_passport and verify_passport.

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

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

The description gives no guidance on when to use this tool versus alternatives (e.g., get_passport for retrieving, verify_passport for checking). There is no mention of prerequisites, frequency, or contexts where issuance is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'List trust audits' only implies a read operation and gives no details on possible side effects, return formats, filtering behavior, or access requirements. It adds minimal value beyond the tool name.

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

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

The description is extremely concise with no wasted words. It is a short, direct phrase that is easy to parse, though it could be slightly more informative. However, it is appropriately structured for a simple list operation.

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

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

The tool is simple (one optional parameter), but the description lacks any mention of what is returned, how filtering works, or any related context. Since there is no output schema and no annotations, the minimal description leaves significant gaps for the agent to infer behavior.

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

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

The schema covers 100% of the parameter, including a description for the 'status' filter. The description adds no additional meaning beyond what is already in the schema, so the baseline score of 3 applies.

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

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

The description clearly states the action ('List') and the resource ('trust audits'), which is specific and distinguishes this tool from sibling list tools like list_campaigns or list_deals. It is unambiguous and directly conveys the tool's purpose.

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

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, nor does it mention any exclusions or prerequisites. It simply states the action without contextual cues, 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.

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 states 'List', implying read-only, but does not mention pagination, ordering, default behavior when no status filter is given, or any side effects. This is a significant gap for a tool with no 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.

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

The description is a single, short sentence with no filler or repetition. It is front-loaded with the action and object, but it could include more useful context without becoming verbose.

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

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

Given the tool's low complexity (one optional parameter, no output schema), the description is minimally viable. However, it omits any mention of default behavior or return format, leaving the agent to infer these from the tool name and schema.

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

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

The schema fully documents the single optional 'status' parameter with an enum and description. The tool description adds no extra semantic meaning beyond what the schema already provides, placing it at the baseline for high schema coverage.

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

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

The description uses a specific verb ('List') and resource ('marketing campaigns'), clearly differentiating it from sibling tools like create_campaign or list_deals. However, it does not explicitly contrast it with alternative tools, so it is not a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The intended usage is only implied by the tool name and the verb 'List', with no explicit context.

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

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

With no annotations, the description must carry the burden of disclosing behavioral traits. It only states that it lists capabilities, but does not disclose pagination, ordering, safety (read-only), or what a capability represents. This is minimal 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.

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

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple list tool, though it is under-specified rather than over-lengthy.

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

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

The tool has no output schema and no annotations, so the description should explain what is returned (e.g., list of capability names, format, pagination). It does not, nor does it clarify the concept of 'capabilities'. Given the sibling list tools, more context is needed to avoid confusion.

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

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

Schema coverage is 0%, so the description should explain the 'limit' parameter, but it does not. The parameter name is self-explanatory and has a default, giving it slight intrinsic meaning, but the description adds no explicit semantics.

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

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

The description uses a specific verb 'List' and identifies the resource as 'available capabilities in the network', which clearly states the tool's action. However, it does not distinguish this from other list_* tools, though 'capabilities' is a unique resource not covered by siblings.

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

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

No guidance is provided about when to use this tool versus alternatives like list_platforms or discover_agents. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'list', which implies a read-only operation, but it does not explicitly state that, nor does it disclose any other behavioral traits such as pagination, ordering, which deal statuses are included, or whether any side effects occur. This is insufficient for a tool with no annotation support.

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

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

The description is a single, focused sentence that immediately communicates the purpose. There is no filler or redundancy, and it is appropriately front-loaded.

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

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

With no annotations and no output schema, the description offers very little context. It does not mention what a 'payment deal' entails, what the return data looks like, or any operational considerations. For a simple list tool this is barely adequate, but given the lack of structured metadata, the description should be more informative.

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

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

The schema has only one parameter (agent_id) with a description ('Agent ID to list deals for') that covers 100% of the parameter's meaning. The tool description adds no extra semantic value beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'List payment deals for an agent'. It uses a specific verb ('list') and resource ('payment deals') with a clear scope (for an agent). This distinguishes it from sibling tools such as create_payment_deal or list_jobs.

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

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

The description implies the tool should be used when you need to retrieve payment deals for a specific agent, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The usage context is only implied.

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

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

No annotations are provided, so the description carries the burden. It clarifies the scope ('open jobs/bounties') and that they are claimable, but it does not disclose pagination, ordering, authentication needs, or response format. For a simple read-only list tool, this is adequate but not thorough.

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

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

The description is a single, front-loaded sentence that conveys all essential information without fluff. Every word contributes meaning; it is highly concise and well-structured.

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

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

For a simple list tool with two optional parameters and no output schema, the description is sufficiently complete. It states the purpose and the filtering nature. However, the lack of output schema means the agent knows it lists jobs but not their exact fields, which is a minor gap.

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

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

Schema description coverage is 100%, with both parameters (limit and category) having clear descriptions. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('List') with a clear resource ('open jobs/bounties') and purpose ('agents can claim and complete for payment'). This clearly distinguishes it from siblings like post_job, submit_job, and claim_job.

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

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

The description provides clear context: this tool lists open jobs/bounties available for agents to claim and get paid. It implies when to use it (when looking for available work) but does not explicitly name alternatives or exclusions, so it misses the top score.

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

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

With no annotations provided, the description relies on the verb 'List' to convey that this is a read-only operation. However, it does not disclose any additional behavior such as authentication requirements, pagination, or data freshness, which would be helpful for a complete understanding.

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

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

The description is a single, focused sentence with no wasted words. It immediately communicates the subject and key content.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is adequate. It conveys the return content in enough detail, though additional context about the static nature of the list or ordering might enhance completeness.

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

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

The tool has no parameters, so the schema is trivially covered. The description appropriately omits parameter details, and the 0-parameter baseline applies.

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

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

The description clearly states the tool's function: listing supported platforms, and adds the distinctive detail 'with trust transfer ratios', which distinguishes it from sibling list tools like list_deals or list_campaigns.

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

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

The description implies but does not explicitly state when to use this tool over alternatives. It provides no exclusionary criteria or mention of related tools, so the agent must infer from the name that it's for platform enumeration.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what data is included in 'statistics', or any limitations such as time ranges or aggregation methods. This is a significant gap for a tool that is otherwise opaque.

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

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

The description is a single concise sentence that front-loads the purpose without unnecessary words. It is appropriately sized for the tool's simplicity, though it sacrifices detail for brevity. It is not verbose but lacks substance to fully inform the agent.

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

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

Given the absence of annotations, output schema, and detailed description, the tool is under-specified. It does not convey what network statistics are available, how they are formatted, or any expected response structure. For an agent to invoke this tool effectively, more context would be necessary.

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

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

The tool has zero parameters, and the input schema shows an empty properties object. With no parameters to describe, the baseline of 4 applies. The description does not need to add parameter semantics, though it could mention that no inputs are required, which is already evident from the schema.

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

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

The description clearly identifies the tool as retrieving 'Joy network statistics' with a specific verb and resource. It is distinct from sibling tools like get_org_dashboard or get_wallet, which target different data types. However, it does not specify what kind of statistics are returned, preventing a perfect score.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contextual triggers. The tool simply states what it does without clarifying its use case among the sibling tools.

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

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

With no annotations provided, the description carries the transparency burden. It adds the trust-only vs. paid distinction, which hints at economic behavior, but it does not disclose other side effects such as job visibility, approval flow, or any wallet requirements beyond what the schema already notes.

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

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

A single, front-loaded sentence immediately states the core purpose, then adds the most critical usage distinction. No filler, every word earns its place.

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

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

For a creation tool with 7 parameters and no output schema, the description is minimal but sufficient when combined with the schema. It captures the essential behavioral choice (trust-only vs paid) without going into exhaustive detail. However, it does not mention post-posting behavior or how agents discover the job, leaving some context to inference.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds slight semantic value by explaining the practical difference between bounty_cents=0 and bounty_cents>0, but this largely mirrors the schema's own note on bounty_cents. No additional meaning is provided for the other six parameters.

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

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

The description clearly states the action ('Post a job') and the resource ('job') with the purpose 'for other agents to complete'. This distinguishes it from sibling tools like claim_job, submit_job, and approve_job, which handle subsequent lifecycle stages.

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

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

The description gives concrete usage guidance for the key parameter pairing: 'Use bounty_cents=0 for trust-only jobs, or specify amount for paid jobs.' This clarifies when to use different configurations, though it does not explicitly contrast with alternatives or state when not to use the tool.

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

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

With no annotations provided, the description carries the full burden of disclosure. It does reveal the core behavioral outcomes (recover+bonus or lose stake), but it omits other important traits such as authorization constraints, finality, impact on balances or reputation scores, and whether the operation is reversible. This is somewhat thin for a financial/reputation 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.

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

The description is a single, front-loaded sentence with no redundancy. It conveys the essential purpose and outcome in a compact format, making it easy for an agent to parse quickly.

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

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

For a tool with 4 parameters and no output schema, the description provides the core purpose and outcome, but lacks context on prerequisites (e.g., stake must exist and be pending), return values, and side effects beyond the stake itself. It is adequate but has gaps that could lead to incorrect usage without additional information.

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

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

The schema covers all four parameters with descriptions, so the baseline is 3. The description adds value by explicitly mapping the 'outcome' parameter to its implications: success recovers stake plus bonus, failure loses the stake. This goes beyond the enum labels and enriches the parameter semantics.

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

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

The description clearly states the action ('Resolve a reputation stake') and specifies the two possible outcomes with their consequences ('success: recover + bonus, failure: lose stake'). This distinguishes it from sibling tools like create_stake and get_stakes, which serve different purposes.

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

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

The description implies the tool is used to resolve an existing stake, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The context is clear for a user familiar with staking workflows, but less explicit for an agent needing decision guidance.

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

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

With no annotations, the description carries the full burden of disclosing side effects, but it only states 'Submit completed work' and mentions optional provenance. It does not explain whether the submission is final, what state transition occurs on the job, whether resubmission is allowed, or what the response will be. The provenance trust boost is already described in the input schema, so the description adds little behavioral transparency beyond that.

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

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

The description is a single sentence that front-loads the core action and resource, with a parenthetical version note that is informative without bloating the text. Every word earns its place.

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

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

Given the complexity of the nested provenance object and the absence of an output schema, the description should clarify what happens after submission, whether the job transitions to a review state, and what the success/failure response includes. It only mentions submitting completed work and the optional trust boost, leaving significant gaps for a workflow tool that sits between claim_job and approve_job.

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

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

The schema provides 100% coverage of parameters, including a rich nested provenance object, so the description does not need to add detailed field explanations. The phrase 'Submit completed work' echoes the submission parameter but adds no new semantics beyond what the schema already states.

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

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

The description clearly states the action ('Submit completed work') and the target resource ('a claimed job'), using a specific verb that distinguishes it from siblings like claim_job, approve_job, and post_job. It also adds a version note about provenance, reinforcing the tool's purpose.

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

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

The phrase 'for a claimed job' implies the prerequisite that the job must be claimed before submission, and the context of submitting completed work implicitly differentiates this from claiming or approving jobs. However, it does not explicitly mention alternatives or when not to use the tool, so it misses the top score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action without explaining side effects, return format, or safety characteristics. It does not contradict annotations, but it is insufficient for transparency.

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

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

The description is a single concise sentence, which is efficient but under-specified. It earns its place but lacks substantive information that would make it highly conciated and useful.

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

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

Given the absence of annotations and output schema, the description is too minimal. It does not describe what verification entails, what the return value is, or any side effects, leaving the tool incomplete for an agent to use correctly.

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

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

The schema description covers 100% of the parameter, including the token format. The tool description adds no parameter information, so with high schema coverage a baseline score of 3 is appropriate.

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

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 'portable passport token', which is specific and distinguishes from siblings like get_passport and issue_passport. However, it does not explicitly contrast with alternatives, so it is not a 5.

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

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

No guidance is provided on when to use this tool vs alternatives. The description only gives the action without context, exclusions, or references to other tools, leaving the agent to infer usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the purpose ('verify if...') and omits any details about side effects, return format, permissions, or whether this is a read-only operation. This is a significant gap for a tool that may trigger trust evaluation logic.

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

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

The description is a single, front-loaded sentence with no redundant wording. It efficiently conveys the tool's purpose and usage context without wasting tokens.

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

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

The tool is relatively simple, and the schema fully documents its parameters. However, with no output schema and no annotation coverage, the description leaves unanswered questions about return values (e.g., boolean vs. detailed report) and any side effects. 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.

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

The input schema has 100% description coverage for all three parameters (agent_id, platform, min_trust), so the schema does the heavy lifting. The description adds no extra meaning beyond what the schema already provides, meriting the baseline score.

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

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

The description uses a specific verb 'Verify' with a clear resource ('if an agent meets minimum trust threshold') and context ('before delegating a task'). This distinguishes it from the sibling tool get_trust_score, which likely retrieves a raw score rather than performing a threshold check.

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

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

The phrase 'before delegating a task' provides a clear situational context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the context alone is sufficient for basic usage guidance.

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