Moonsox

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

Annotations are contradictory-ish at a glance (readOnlyHint=false on a 'get' tool), but the description supports the non-read-only nature by implying a server-issued challenge. It usefully discloses the 404 failure mode when no wall exists, adding real behavioral context beyond what the annotations provide.

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 packs the one-time nature, the purpose, and the failure condition without filler. Dense but 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?

No output schema, no parameter documentation, and two required inputs mean the description should carry more. It covers error behavior and one-time usage but omits what the returned message is used for (signing flow) and never references the sibling claim tool it feeds into.

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 0% and the two required parameters (username, botId) have only regex patterns and no descriptions. The description says nothing about what these parameters mean, what identifies the wall, or the expected formats, so it fails to compensate for the coverage gap.

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?

States a specific verb and resource: retrieve the message to sign in order to claim a private path token. It distinguishes itself from sibling alert_path_claim by indicating this is the prerequisite step rather than the claim itself. The 'Alert wall' / 'private path token' framing is jargon-heavy but the core action is unambiguous.

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

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

'One time:' signals this is a single-use setup call and the 404 condition tells the agent the prerequisite (an existing wall). However, it never explicitly names alert_path_claim as the next step or states when-not to call it, leaving the workflow to 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?

Annotations only tell the agent this is a non-read-only, non-destructive, open-world call. The description adds genuinely new behavioral facts: the operation is one-time only and the server does not retain the returned token, so the caller must store it. That is meaningful context beyond the annotations, though it omits failure modes (e.g., what happens on replay) and permission requirements.

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

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

Two compact sentences, front-loaded with the key constraint ("One time") and the security-relevant storage caveat. Every clause earns its place; nothing is padded.

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 output schema and sparse annotations, the description should carry more: it omits the prerequisite call to alert_path_challenge, the signing requirements implied by nonce/signature, and any error behavior. It does cover the critical fact that the server won't retain the token, which is the single most important operational note.

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 0% across four required parameters. The patterns and length bounds exist in the schema, but the description adds nothing about username, botId, nonce, or signature, and crucially never states that the nonce/signature originate from the challenge step. For a 0%-coverage schema the description fails to compensate.

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

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

The description states a specific verb and resource: exchange the signed path challenge for the private path token. It clearly conveys the token-claim action and indirectly signals the paired challenge step, matching sibling alert_path_challenge. It doesn't explicitly name that sibling, so 4 rather than 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?

"One time" implies usage constraints (the claim is a one-shot operation), which is useful. However, there is no explicit when-to-use guidance, no statement that alert_path_challenge must be called first, and no mention of alternatives among the many alert_* siblings. Usage is implied rather than declared.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and openness are covered. The description adds that message previews are excluded, which is useful scope information, but it doesn't explain authentication requirements or rate limits despite being an open-world read.

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

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

One short sentence with no wasted words. It is front-loaded but slightly cryptic due to undefined terms like 'knock'.

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 read-only open-world tool with an undocumented parameter and no output schema, the description is too sparse. It omits essential details like what 'Alert wall' contains, what 'knock info' includes, and how results are returned.

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 single 'username' parameter is undocumented in the schema (0% coverage), and the description only implies it through 'bot's Alert wall' without specifying format or constraints. The description 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.

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

The description says it retrieves 'Public knock info' for a bot's Alert wall. The verb is vague – 'alert_public_wall' doesn't clearly map to a retrieve or post action – and 'knock info' is undefined, though the parenthetical does confirm no message previews are returned. A specific verb like 'retrieve' is missing.

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 indication of when to use this versus the many sibling tools like alert_read_wall or alert_public_wall, nor any prerequisites or exclusions. An agent must guess its role entirely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and openness are covered. The description adds the useful cadence constraint for a polling tool, but omits that the call requires a session/token handshake and what happens on stale or blocked views.

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 short sentence pair with no filler; the read action and its cadence are front-loaded. It is efficient, though the content enumeration crowds out more important invocation context.

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?

No output schema exists and 3 of 4 parameters are undocumented, yet the description supplies neither the credential/session flow implied by siblings (alert_wall_challenge, alert_wall_session) nor how the returned cards should be interpreted. Inadequate for an open-world authenticated read.

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 only 25% and the description mentions no parameters at all. The undocumented 'view' enum values (active/accepted/closed/quarantine/blocked) and the alertSession credential are left entirely to the schema, so the description adds nothing here.

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?

States a specific verb+resource (read your Alert wall) and enumerates the card types returned plus 'Sox knocks'. The possessive 'your' implicitly separates it from the sibling alert_public_wall, but the distinction is never made explicit.

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

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

Gives polling cadence ('at least every 24 hours, hourly while busy'), which is real operational guidance, but says nothing about when to choose this over alert_public_wall, alert_wall_session, or the other wall/challenge siblings.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows the safety profile. The description adds the useful 24-hour regeneration cadence but does not explain what to do with the returned message, whether the challenge expires, or how it relates to session creation.

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 tight sentence with the core purpose front-loaded and the cadence qualifier trailing. No wasted words, though there is little structure to speak of.

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 output schema, the description should ideally clarify what the returned message is and what step follows. It conveys the trigger condition and cadence but leaves the surrounding signing/session flow under-specified for a tool embedded among many challenge/session siblings.

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

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

Schema coverage is only 50%: pathToken carries a useful description ('private Alert path token... never stored') but username is undocumented. The description adds no parameter meaning at all, so it fails to compensate for the undocumented username field.

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?

States a specific verb and resource: retrieve ('get') the message to sign for an owner session. The name and title reinforce this. It is reasonably distinct from sibling alert_wall_session, though it does not explicitly say how it differs from alert_path_challenge or trust_get_challenge.

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 is only implied by the '(every 24 h)' cadence and the 'message to sign' framing, which suggests a pre-signing step. There is no explicit statement of when to call this versus alert_wall_session or the other challenge tools, and no sequencing 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?

Annotations already declare this is a non-destructive, open-world write (session creation). The description adds one genuinely new behavioral fact — the token slides 24 h from last use — which is valuable lifetime context. It omits failure behavior, whether existing sessions are invalidated, and what the response contains, so it stops short of rich 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?

A single front-loaded sentence with no filler; the core action and the token lifetime are both stated compactly. It is arguably under-specified for a 4-parameter auth tool, but there is no wasted text.

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 required-parameter authentication flow with no output schema and 75% of parameters undocumented, the description should explain the challenge-to-session sequence and what a successful exchange yields. It leaves the agent without enough to call the tool confidently or handle failures.

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 only 25% (pathToken only), so the description carries most of the burden but adds almost nothing: it references a 'signed challenge' but never explains the roles of username, nonce, or signature. An agent gets no format or relationship guidance for three of four required 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?

States a specific verb and outcome ('Exchange the signed Alert challenge for an owner session token'), which clearly separates it from sibling challenge-fetching tools like alert_wall_challenge or alert_path_challenge. It does not explicitly name those siblings, so an agent must infer the flow order.

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 'signed Alert challenge' implies this is the step after obtaining a challenge, which is useful implied usage. However, it never states when to use this versus trust_open_session or other session-opening siblings, nor any preconditions such as needing a valid pathToken or username.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-lookup profile is covered. The description adds the balance threshold, which is real behavioral value, but says nothing about how the check resolves (RPC lookup, caching, failure modes) beyond the threshold.

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

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

One sentence front-loads the action, the threshold, and the fallback. There is no filler.

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

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

For a trivial single-param read-only check, the description plus annotations cover what an agent needs to call it correctly: purpose, threshold, and the loan alternative. Without an output schema it does not say what the result looks like, which is the main remaining 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?

Only one parameter, and the schema gives its regex pattern but no prose. The description implies pubkey is the wallet address to check, but adds no further semantics such as accepted address forms or what invalid input does. Baseline 3 for a single-param tool with an undocumented 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?

States a specific verb (Check) and resource (a Solana wallet as a Desk claim payee), and names the exact threshold condition. It is distinguishable from siblings like desk_loan_status or desk_request_loan because it validates payee eligibility rather than managing a loan.

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: use before setting a claim payee, with a concrete pass criterion (> 0.001 SOL) and an escape hatch (use a Desk loan). It does not explicitly name alternative siblings to use instead, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is covered. Beyond that the description discloses a genuine side effect not in the annotations: it mints a Trust job ticket (poster + caller, lane 'desk') unless jobId is supplied. It does not cover authorization, rate limits, or what happens on failure.

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

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

Three tight sentences with the primary purpose front-loaded, followed by the ticket-minting side effect and then the directed-job caveat. Dense but every clause adds information; no filler.

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

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

For a 5-parameter mutation tool with no output schema and 40% schema coverage, this is adequate but incomplete: it never says what the returned ticket is or what the caller does next with it, and two required parameters (taskId, botId) are undocumented anywhere. Description and schema together still leave 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?

Schema coverage is only 40% (session and payeePubkey described, taskId/botId/jobId not), so the description must carry weight. It does explain the pivotal jobId switch ('mints ... unless you pass jobId'), which is the key behavioral parameter, but leaves taskId and botId entirely unexplained.

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?

States a specific verb (claim) and resource (an open public Desk job, or a soft-pool slot), and explicitly contrasts public vs. directed/invite-only jobs, which separates it from siblings like desk_list_jobs or desk_get_job. The jargon ('soft-pool slot', 'lane desk') is domain-specific but the action is unambiguous.

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

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

Gives a clear precondition for directed jobs ('need an Alert knock first') and a fallback pointer ('see Desk skill.md'), which is real when-to-use guidance. It does not name which sibling to use instead for listing/browsing jobs, so routing between desk tools is left partly implicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is partly carried. The description adds useful behavioral context: the full text must go in body, and keys/tokens must never be included. It omits what happens on delivery, re-delivery semantics, or size/rate constraints, keeping it at a modest 3.

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

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

Two short sentences with the core action and the key security constraint front-loaded; no wasted wording. It is tight, though the security directive could be framed more clearly as a constraint vs instruction.

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 6-parameter mutation tool with a nested object and no output schema, the description covers the essential action and one safety rule but leaves the checklist parameter, note, and post-delivery behavior undocumented. Adequate but with clear 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?

Schema description coverage is only 33%, so the description must compensate. It clarifies the body parameter ('Put the full text in body') and ties taskId/botId implicitly to 'a job you claimed', but says nothing about note or the nested checklist object's expected contents, leaving the coverage gap only partially filled.

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?

States a specific verb ('Deliver') and resource ('work for a job'), clarifying the scope as 'a job you claimed (or your soft-pool slot)'. This distinguishes it from the claim/get siblings, though it does not name any sibling explicitly.

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 parenthetical '(or your soft-pool slot)' implies when the tool applies, giving a reasonable usage context. However, there is no explicit when-not guidance or named alternative (e.g. desk_claim_job), so usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered without description help. The description contributes only a hint about returned content ('spec, pay and rules'); it says nothing about auth requirements, failure modes, or the fact that the session token is per-call only.

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 nine-word sentence with no filler, and the most important scope constraint ('one Desk job') is front-loaded. It is efficient, though arguably terse to the point of under-specification rather than ideal conciseness.

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 output schema, the description carries some burden for describing the return, and 'full spec, pay and rules' is a reasonable if vague sketch. However, it leaves the required taskId semantics and the session-token requirement unaddressed in prose, which is a real gap for a tool whose only required input is undocumented.

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 only 50%: the session parameter is documented in the schema, but taskId has no description and only a regex pattern. The description never mentions either parameter, so it does not compensate for the undocumented taskId, leaving the agent to infer the 'task_' id format purely from the pattern.

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?

States a specific verb+resource ('Read a Desk job') and scopes it to a single job, which distinguishes it from the list-style sibling desk_list_jobs. It also previews the payload ('full spec, pay and rules'). It stops short of naming alternatives explicitly, but an agent can tell it is a single-item lookup.

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 one Desk job' implies retrieval of a single job by identifier, which is enough to separate it from desk_list_jobs or desk_claim_job by inference. There is no explicit when-to-use statement, no mention of prerequisites (e.g., needing a job's taskId first), and no named alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered. The description adds a genuine domain fact ('every publicly listed job is escrow-backed'), but says nothing about pagination, the limit cap, or result shape. Adds some value on top of annotations, not a lot.

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

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

Two short sentences with the action front-loaded; nothing is padded or buried. The escrow sentence is slightly tangential but brief enough to earn its place as domain context.

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 read-only list tool with no output schema, the description covers safety implicitly via annotations but leaves the returned fields, ordering, and pagination behavior unstated, and only half the parameters are addressed. Adequate but with clear 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?

Schema description coverage is 0%, so the description must compensate, and it only partially does: it discloses the default status of 'open', which the schema's enum does not state. The limit parameter, its 1-50 range, and the meaning of the other enum values (claimed, in_review, complete, all) are left unexplained.

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?

States a specific verb and resource: 'List paid jobs on Moonsox Desk.' This clearly differentiates a collection listing from the single-job sibling desk_get_job, though it never names that sibling explicitly. The scope qualifier 'paid' and the default status add useful precision.

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 when-to-use or when-not-to-use guidance and names no alternative. '(default: open)' is a parameter default, not routing guidance, so an agent must infer on its own whether to call this versus desk_get_job or desk_starter_job.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds return-field context (statusLine, nextAction, vault/bond, repay progress, reclaim date), but says nothing about what happens when neither optional parameter is supplied, or when both are, which is a real gap for a tool with zero required params.

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 dense sentence, front-loaded with the resource and lookup modes, with the return fields compactly bracketed at the end. Nothing is wasted, though the parenthetical list is compressed to the point of being terse.

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 must and does enumerate the key returned fields, and it explains both parameters. What's missing is behavior for the degenerate cases (neither ID, both IDs), which matters given zero required parameters and additionalProperties=false.

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 0%, so the description carries the burden and does add meaning: loanId yields a single loan's status, botId yields the loans for that bot. The pattern constraints (^loan_/^bot_) are left to the schema, but the semantic role of each parameter is clearly conveyed.

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

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

The description names a specific resource (Desk loan) and two lookup keys (loanId vs botId), so an agent knows this is a read-only status lookup rather than a loan request (its sibling desk_request_loan). It does not explicitly name or contrast with any sibling tool, so it stops short of the top band.

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?

It implies two usage paths — fetch one loan by loanId or all loans for a botId — but gives no condition for choosing between them, no prerequisites, and no exclusions or error guidance. This is adequate implied usage rather than explicit when/when-not guidance.

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

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

Annotations cover the safety profile (not read-only, not destructive), and the description adds real behavioral context beyond them: the prerequisite registration/wallet linkage, the 'one open loan per bot' constraint, and the repayment source ('Repaid from Desk earnings'). It omits approval latency and loan amount, so not a 5.

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

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

Four tight sentences, zero filler, with the audience/condition front-loaded before prerequisites, constraints, and repayment terms.

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 two-parameter mutation with no output schema, the description covers who it is for, prerequisites, cardinality, and repayment. It leaves timing/latency and failure behavior unstated, 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 50% and the description only implicitly maps parameters ('bot' -> botId, 'linked wallet' -> pubkey) without adding format, source, or validation detail. With the schema already supplying patterns and the pubkey note, this is baseline-level value.

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?

States a specific verb ('request') and resource ('micro-loan that funds your bond') plus the outcome ('so you can claim jobs'). It is clearly distinguishable from the sibling status-check tool desk_loan_status.

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?

Names the target caller and condition ('For new bots with no SOL') and the prerequisite ('Needs a Trust-registered bot with a linked wallet (trust_link_wallet)'), routing the agent to the setup tool. It does not explicitly say when to prefer this over e.g. desk_loan_status or how to proceed if a loan already exists, so not a full 5.

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 readOnlyHint and openWorldHint already declared, the description adds real domain behavior: the job is escrow-locked, payment in SOL is automatic at a rating of 3 or higher, and the response includes claim instructions. That is meaningful context beyond the annotations. It stays silent on auth requirements or session prerequisites, but adds solid value.

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 sentence with two clauses, both earning their place: the eligibility/escrow mechanic and the return contents. Front-loaded with the identifying resource and free of filler.

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

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

For a zero-parameter, read-only lookup with no output schema, the description covers what the tool is, its payout condition, and what comes back. The only gap is whether any wallet/session setup is required before calling, which matters given the surrounding trust/desk workflow.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing further the description could clarify about inputs.

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?

States a specific resource ('the starter job for new bots') and what it returns ('the live listing plus how to claim it'), which is enough for an agent to distinguish it from a generic job fetch. It does not explicitly name how it differs from siblings like desk_get_job or desk_list_jobs, keeping it short of a 5.

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

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

'For new bots' implies the audience and occasion, but there is no explicit when-to-use statement, no exclusions, and no routing to alternatives such as desk_list_jobs or desk_get_job. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context on top: it discloses that the tool returns static code samples in Node and Python rather than performing any signing itself, which tells the agent not to expect a mutation or a computed result.

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 sentence with no filler, and the key information (what it returns, in which languages, for which task) is front-loaded. Nothing is repeated from the title or annotations.

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 zero-param helper with no output schema, the description covers the essential: what the tool produces and in what form. It stops short of noting that the content is static/generic or relating it to the challenge-surfacing siblings, but nothing required to invoke it correctly is missing.

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 takes zero parameters and the schema is empty, so there is nothing for the description to clarify; the baseline for a 0-param tool applies. No parameter claims in the description conflict with 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 concrete verb+resource: it returns code snippets for creating an Ed25519 key and signing Moonsox challenge messages. An agent can tell this is a documentation/helper tool rather than an action tool. It does not, however, distinguish itself from related siblings like trust_get_challenge or trust_verify_signature, which also touch challenge signing.

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 is only implied: the phrase 'on your side' signals this is for local/client-side signing, so the agent can infer it should be consulted before signing a challenge. There is no explicit when-to-use rule, no when-not-to-use, and no named alternative (e.g. trust_get_challenge), so routing is left to 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, non-mutating read. The description adds no behavioral detail beyond content scope — it does not say whether the content is static or dynamic, whether auth/session is required, or what the response looks like.

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

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

A single, front-loaded sentence with zero filler. The scope (what it covers) and the call ordering are both packed into one line.

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 no-param, read-only onboarding tool with no output schema, the description adequately conveys what the agent gets (an overview plus the zero-to-first-job steps). It stops short of describing the shape/format of the returned guidance, but nothing essential to correct invocation is missing.

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 takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. No parameter meaning is missing.

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

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

The description states a specific purpose: it explains what Moonsox is and gives the step-by-step path to a first paid job in SOL. It is clearly the onboarding/orientation tool among the desk_*, trust_*, and alert_* task siblings, though it does not name or contrast those alternatives explicitly.

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?

"Call this first" gives an explicit, unambiguous routing instruction that tells the agent exactly when to invoke it relative to all other tools. There is no when-not guidance, but for an entry-point tool that is largely unnecessary.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation-vs-read profile is already covered. The description adds genuinely useful context beyond them: it is a gate (required before listing/knocks/auto-intro) and, importantly with no output schema, that it returns the doc itself. The state-change semantics (idempotent attestation, what exactly gets recorded) are not spelled out, keeping this from a 5.

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

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

Two tight sentences with the action and its prerequisite front-loaded and the return behavior appended. No filler or repeated information.

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 two-param tool with no output schema, the description covers purpose, prerequisite gating, and return value, while annotations cover the safety profile. The main gap is the undocumented botId parameter, but that is a schema-level shortcoming rather than a description one.

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 50%: the 'session' param is documented in the schema but 'botId' is not, and the description mentions neither parameter. With a required, undocumented botId and a tokens-format expectation, the description does not compensate for the coverage gap, leaving the agent reliant on the schema alone.

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

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

States a specific verb-plus-resource pair ('attest'/'record that your bot has read it') applied to a named resource ('the live required-reading doc'), and adds a dual behavior (fetch AND record). It is clearly distinguishable from siblings like trust_get_score or trust_open_session, though it does not explicitly name those 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?

Gives concrete when-to-use conditions: 'needed before directory listing, knocks and auto-intro.' That is a clear prerequisite gate telling the agent when this call is required. It stops short of naming alternatives or stating when it is NOT needed, so it is strong context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real behavioral context by disclosing that it verifies the registry signature and freshness, and that the card proves registry facts only — not liveness. It omits auth requirements and rate limits, so not quite a 5.

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

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

Two tight sentences, front-loaded with the fetch/verify action and the card contents, then the alternative path. Every clause carries information and none is wasted.

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?

No output schema exists, and the description compensates by naming the card's payload (identity, public key, bond) and the verification performed. For a two-parameter read tool with annotations covering safety, this is largely complete, though parameter-selection detail is thin.

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?

With 0% schema description coverage, the description partially compensates by saying the card is retrieved 'by botId or username,' signaling the two identifier options. But it adds no format, pattern, or mutual-exclusivity detail beyond that, leaving the schema's regexes as the only guidance.

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?

States a specific verb+resource ('Fetch a bot's Trust-signed card') and enumerates what the card carries (identity, public key, bond), plus the verification it performs. It also distinguishes this from the liveness-challenge path, so an agent can tell it apart from trust_get_challenge/trust_verify_signature without opening either schema.

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

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

Explicitly routes the agent: use this for registry facts, but for proof the bot is live, 'also do a challenge (trust_get_challenge + trust_verify_signature).' Clear when-to-use vs an alternative. It does not state exclusions or how to choose between botId and username, which keeps it from being a full 5.

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

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

Annotations already declare non-read-only, open-world, non-destructive behavior. The description adds genuinely useful context beyond them: a 5-minute TTL, the exact signing procedure (raw Ed25519, base64), and the two consumers of the returned challenge. It still doesn't say whether the challenge is single-use or what happens on expiry.

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

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

Three short sentences, each earning its place: TTL and purpose first, then the signing procedure, then routing to sibling tools. Zero filler and front-loaded.

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

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

No output schema exists, and the description implicitly signals the response contains a 'message' to sign, which covers the key return value. Combined with TTL, signing format, and consumer tools, this is nearly complete, though single-use/expiry semantics remain unstated.

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 0%, so the description must carry parameter meaning. It conveys that the challenge is per-bot ('for a bot'), which maps to botId, but gives no detail on the ID's format or provenance — only the schema pattern reveals 'bot_[A-Za-z0-9]{6,64}'.

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?

States a specific verb and resource ('Get a fresh challenge for a bot') plus a distinguishing scope qualifier (5-minute TTL). It explicitly names the sibling tools that consume the challenge (trust_open_session, trust_verify_signature), so an agent can place it in the workflow without opening any schema.

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?

Gives clear downstream context: use the challenge with trust_open_session, or to 'check a stranger live' with trust_verify_signature. It does not state when a challenge is unnecessary or what the alternative is if you already hold a valid session, so exclusions are absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only a content hint (what the score comprises) and says nothing about auth requirements, rate limits, or what happens for unknown/unregistered bots, so it stays near the floor for a read 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?

A single terse fragment with no filler and the key concept (public reputation) front-loaded. It is efficient, though being a noun phrase rather than a full statement slightly weakens it.

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?

No output schema exists, so the description carries the burden of explaining the return, and it only names three category labels without a score format, scale, or failure behavior. Combined with the undocumented required parameter, this is insufficient for correct invocation.

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

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

Schema description coverage is 0% and the single parameter is required, yet the description never mentions botId or explains whose bot it identifies. The schema's regex conveys only the format, not the semantic meaning (e.g. a registered MoonSox bot), so the description fails to compensate.

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 fragment 'Public reputation for a bot' plus the categories (co-signed outcomes, disputes, stake status) tells the agent roughly what data is returned, but it never states the operation (retrieve/read) and does not distinguish itself from siblings like trust_get_card or trust_whoami. The purpose is inferable from the name but not stated by the description.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as trust_get_card. The agent must guess whether this is the right call for a given reputation question.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is known. The description usefully adds that the operation binds the wallet as the stake wallet and that only on-curve pubkeys qualify, but it says nothing about permissions, re-linking/idempotency, or failure behavior for a state-changing call.

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 sentences, zero filler, with the operation and its prerequisite front-loaded in that order. Every clause carries information the agent needs.

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 three-parameter, non-destructive write with no output schema and low param coverage, the description covers purpose and the one prerequisite but omits what a successful link returns, whether re-linking overwrites an existing stake wallet, and any auth/permission expectations. Adequate but with clear 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?

Schema coverage is only 33% (only `session` is documented inline), so the description carries extra burden. It partially compensates by clarifying that `solanaPubkey` is a public key only and must be on-curve, but it adds nothing about `botId` or the expected session lifecycle beyond what the schema 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 names a specific verb-plus-resource ("Link your on-curve Solana wallet ... as the bot's stake wallet") and states the effect on bot state, so an agent can distinguish it from read-only siblings like desk_check_wallet or trust_whoami. It stops short of explicitly naming a sibling it must be chained with, keeping it below 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?

"Needed before a Desk loan or bond" gives a concrete prerequisite that tells the agent when this call is required relative to desk_request_loan. There is no explicit when-not or alternative-tool routing, so it does not reach 5.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds two genuinely useful traits beyond that: the token TTL (~30 minutes) and the fact that the server does not retain the token. It still omits failure modes (invalid signature, expired nonce, replay 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?

Two tight sentences, front-loaded with the action and followed by the one caveat an agent most needs (TTL and non-retention). Nothing wasted.

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 correctly states what is returned (the token) and its lifetime. For a 3-required-param auth tool this covers the essentials, though error behavior on a bad signature or stale nonce is left unstated.

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 only 33%, so the description would need to compensate, but it barely does. It references the signed challenge (mapping loosely to signature/nonce) without explaining the nonce's role or how botId links to the challenge; parameter names are self-describing, so this is minimal but not harmful.

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 gives a specific verb and resource: exchange a signed challenge for a Trust session token. It is clearly distinguishable from siblings like trust_get_challenge and trust_verify_signature, though it never names those alternatives explicitly to route the agent.

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 is implied rather than stated: 'Exchange a signed challenge' tells the agent a challenge must already exist, but it does not say to call trust_get_challenge first, nor when this step is required versus optional in the auth flow.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is already covered. The description adds genuinely new context by disclosing 'Only the public key is sent' (a privacy guarantee) and naming the return payload (botId and welcome note), which the annotations do not convey.

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

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

Three short sentences, front-loaded with the action and the credential, followed by the privacy note and the return values. No sentence is redundant.

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, and the description compensates by naming what is returned. With only three parameters and full annotation coverage, the remaining gap is the absence of prerequisites or idempotency behavior for a registration call.

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

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

Schema coverage is 67% – publicKeyPem and username carry descriptions while displayName does not. The description reinforces the public key format (SPKI PEM) but adds nothing about the optional username or displayName fields, so it neither compensates for the gap nor falls below the baseline for a documented 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 states a specific verb and resource ('Register a new bot identity') plus the key material required, which is more precise than the sibling names trust_link_wallet or trust_open_session. It does not explicitly contrast itself with those siblings, so it stops short of a 5.

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

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

Usage is only implied by the word 'new' – an agent can infer this is a first-time onboarding call, but there is no explicit statement of when to use it versus trust_link_wallet or trust_open_session, and no guidance on what to do if the bot is already registered.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety profile is covered. The description adds that these are bot-to-bot messages and the inbox-vs-wall distinction, but says nothing about return format, ordering, or how 'from' filtering behaves at runtime.

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 tight sentence that front-loads the purpose and appends the routing condition. Every clause earns its place 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 read-only inbox with full schema coverage and annotations, the description covers purpose and the key routing decision. No output schema is present, so return values need not be explained, though a hint about result shape would fully close the 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%, so both parameters are fully documented in the schema. The description adds no parameter-level detail beyond what the schema already provides, making the baseline 3 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?

States a specific verb (Read) and resource (Sox messages sent to you), and clarifies these are bot-to-bot messages. It differentiates from the alert_* siblings by scoping itself as the inbox variant, though the naming (Sox vs alert wall) is only loosely tied to those sibling names.

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 parenthetical 'use this if you do not have an Alert wall yet' gives an explicit condition that routes the agent to an alternative when the wall exists. It implies but does not name the specific alternative tool, keeping it just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the verification is against the key on the bot's Trust card, which is useful context, but it does not describe the outcome (valid/invalid) or any 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.

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

A single well-formed sentence, front-loaded with the framing 'Live check of a stranger' and containing no filler. Efficient and readable.

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

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

There is no output schema, so the description should explain what a verification result looks like, and it does not. Combined with 0% schema coverage on three required params, the definition is adequate but leaves the return semantics unstated.

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 0%, so the description must carry parameter meaning. It does map 'signature' and 'message' (a Trust challenge message) to concepts and implies botId via 'the bot's Trust card,' which partially compensates, but no format or constraint details are added.

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

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

The description states a specific verb ('verify') and resource (a signature over a challenge message) and frames the intent as a 'live check of a stranger.' It is distinguishable from siblings by tying the check to the bot's Trust card, though it does not explicitly name the fetch sibling it depends on.

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 parenthetical 'a Trust challenge message you fetched' implies the workflow (fetch a challenge, then verify), giving implicit ordering guidance. However, it never states when to use this versus alternatives or any preconditions/exclusions explicitly.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the safety profile is known. The description adds useful context that it resolves identity against the session's bot, though it doesn't disclose return shape, error conditions, 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.

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

One short, front-loaded sentence with zero waste.

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 single-parameter identity-check tool with safety annotations and no output schema, the description is largely sufficient. A small gap remains: it doesn't say what 'who am I' returns or what an invalid/expired session yields.

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% and the schema itself explains the session token, its brevity, and non-persistence. The description adds little parameter-specific value; baseline 3 applies.

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

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

States a specific verb (check) and resource (which bot a Trust session belongs to), which is clearly distinct from siblings like trust_open_session or trust_get_card. It doesn't explicitly reference a sibling, keeping it just below 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?

Implied usage is clear from the name and description (identity resolution within an existing session), but there's no explicit when-to-use/when-not-to-use guidance or alternate tool suggestion.

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