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

With no annotations, the description carries the full behavioral burden. It usefully discloses the non-obvious two-step contract (it returns {method:'complete', args:[...], contract} and the caller must invoke complete(...args) themselves), which is genuine value. However, it says nothing about permissions, side effects, or idempotency.

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

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

Two tight sentences, front-loaded with the action and followed by the return/usage contract. Nearly every clause earns its place, though the inline object literal is cryptic without further 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 one-param tool with no annotations and no output schema, the description covers the call protocol but leaves the 'job' parameter and the meaning of the 'check' undefined. It is minimally viable rather than complete.

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

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

Schema coverage is 0% and the single required 'job' integer has no description in either schema or description text. The description never explains what 'job' refers to or its expected value, 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?

The description names a specific action ('ask for a completion voucher') tied to the resource, but the domain jargon ('completion voucher', 'job's check') is undefined and there is no differentiation from siblings such as tokyo_job_ticket. An agent gets the gist but not a crisp, unambiguous 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?

It supplies a timing precondition ('once the job's check passes'), which is real usage guidance, but it names no alternatives or when-not conditions and does not clarify how this relates to tokyo_job_ticket or tokyo_trials_submit. Usage is implied rather than spelled out.

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 and does well: it discloses that the voucher hands off to a self-executed contract call, that this 'locks a bond' (a real financial side effect), and that there is a declarative eligibility requirement. It omits failure modes, gas/payment implications, and deadline semantics, keeping it short of 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?

Three tightly packed sentences, front-loaded with the action, then the return shape, then eligibility. No filler; every clause adds actionable 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 tool with no output schema and no annotations, the description compensates well by spelling out the return structure, the required follow-up call, and eligibility. It stops short of explaining the `job` parameter's origin or error behaviors.

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% for the single 'job' integer parameter. The phrase 'for a job' implicitly identifies it as a job identifier, but the description never states the expected id format or source, so it only partially compensates 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+resource ('Ask for an accept voucher for a job') and even specifies the exact return contract shape ({method:'accept', args:[id, deadline, signature], contract}). This clearly separates it from siblings like tokyo_job_complete, which operates at a later lifecycle stage.

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 explicit eligibility context — 'Only declared agents at least 3 days old may accept' — and instructs the agent to invoke contract.accept(...args) from its own wallet. It does not, however, contrast this with alternatives like tokyo_job_complete, so sibling 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?

With no annotations the description carries the full burden. It usefully discloses that the Worker verifies on-chain ownership of the signer, which is real behavioral context, but omits failure modes, idempotency (can a companion be re-linked?), what linking actually mutates, and rate/retry 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?

Three tight sentences with the core action front-loaded, followed by the required workflow and verification note. The trailing 'Open for Rin first' is opaque enough to sit awkwardly as a closing sentence.

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 state-changing, auth-gated tool with no annotations, no output schema, and zero schema coverage, the description covers the input workflow and the verification step but leaves the result, error behavior, and uniqueness constraints unspecified.

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 only partly does. It identifies the four fields and explains their origin (an externally signed message), which helps frame them, but gives no format detail for owner (address?), nonce, or signature encoding.

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: linking this agent to a companion NFT the holder owns. It is unambiguous what the tool does and distinguishes itself conceptually from siblings like tokyo_sign_in. It doesn't explicitly contrast with any named sibling, keeping it at 4.

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 and sequence: the holder must sign externally with link-companion.mjs and hand over the JSON, which is then passed here. 'Open for Rin first' hints at an ordering constraint but is too cryptic to count as explicit guidance, and no alternatives or when-not-to-use cases are given.

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 exist, so the description carries the full behavioral burden. It usefully discloses an availability gate (linked + ownership + owner-enabled) that is not derivable from the schema, but says nothing about what happens when that gate fails, whether the read is cached, or what the failure mode 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?

Two compact sentences that front-load what is fetched before the availability caveat. Minor waste in the parenthetical enumeration and the cryptic closing clause "off until the owner opens it," which is vague about who/what triggers 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?

For a zero-param read tool with no output schema and no annotations, the description covers intent, payload shape, and precondition, which is most of what is needed. It stops short of describing the not-linked/not-owned failure behavior, which an agent gating a call would want.

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 the baseline is 4; there is no parameter meaning to add. The description correctly implies the target is resolved from the agent's link rather than passed in.

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 ("Fetch") and resource ("persona pack") and enumerates the contents (voice, role, holder directives, boundaries), so an agent knows exactly what comes back. It distinguishes itself implicitly from siblings like tokyo_link_companion (which establishes the link this tool requires), though it never names a 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?

Gives a clear precondition for use: it only works while the agent is linked and the holder still owns the companion, and is off until the owner enables it. That is a real when-to-use/when-not signal, but no alternative tool is named for the case where the agent is not linked (e.g. tokyo_link_companion).

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 does disclose real behavioral facts: the action requires a signed-in session, body is a small JSON object, and some actions may respond 'closed' rather than succeed. It does not characterize the mutating paths (gang/create, gang/leave, uc/siege, uc/raid) as state-changing or irreversible, nor describe failure/error behavior beyond the Season 2 note.

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

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

Three sentences with the primary contract front-loaded, which is efficient. However, the 19-value path enumeration is copied verbatim from the schema enum and adds no information, while the truly novel content (body shapes) is compressed into a single parenthetical covering only three paths.

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 generic dispatcher with 19 routes, an untyped body parameter, and no output schema, the description covers the essentials: what to pass, examples, and a hint to read the response message. It is not complete because most body schemas remain unstated and the return shape is only gestured at ('read the answer's message') rather than described, though the absence of an output schema is a mitigating factor.

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 'body' is an untyped free-form object, so the description must compensate — and it does add genuinely new information by mapping three paths to their body keys. But three examples cover only 19 paths, leaving the shape of most bodies (e.g. uc/siege, uc/auction, uc/table) undocumented, and the path list merely duplicates the schema enum.

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 concrete verb and scope ('Call a signed-in game action') and enumerates the exact set of callable paths, so an agent knows precisely what this tool does. It falls short of a 5 because it never separates itself from siblings like tokyo_read, which plausibly overlap with read-flavored paths such as 'me', 'uc/mine', and 'uc/scan/me'.

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 gives per-path body examples (gang/create {name}, gang/join {code}, daily {district}) and a useful operational note that chip games may answer 'closed' until Season 2 districts open. However, it never says when to prefer this tool over tokyo_read, nor explicitly that tokyo_sign_in must precede it, so routing guidance is only implied by the phrase 'signed-in game action'.

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

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

With no annotations, the description carries the full burden: it does disclose that no sign-in is required and that economy figures are on-chain 'data, not a forecast'. However, it omits any mention of rate limits, error behavior, or response shape for a tool that returns ten different payloads.

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 front-loaded sentence with a parenthetical glossary; the structure scales to ten enum values without preamble. It is dense but every clause maps to a parameter option, so little 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?

For a one-param, no-output-schema read tool, the per-option descriptions plus the auth and on-chain-data notes cover what an agent needs to choose correctly. Only return-format details are absent, which is defensible without an output 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?

Schema coverage is 0% and the single enum-only parameter would otherwise be opaque; the description supplies a plain-language gloss for each of the ten values (proof, agents, city, trials, etc.), which is real meaning the schema does not carry. It stops short of describing returned fields per option.

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?

Opens with a specific verb+resource ('Read public Tokyo Futuro state') and then defines every enum value, so an agent can tell it apart from the read/write siblings (tokyo_play, tokyo_sign_in) without opening the 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?

'with no sign-in' signals this is the unauthenticated read path and implicitly contrasts with tokyo_sign_in, but there is no explicit when-to-use statement or named alternative for acting on state (e.g., tokyo_play for mutations). Usage is only implied by the enum glossary.

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 and does disclose the two most important traits: it is free and moves no funds, and it is invoked automatically by other tools. It says nothing about whether the sign-in is idempotent, what happens if already signed in, how long the session persists, or what changes for subsequent calls.

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 covering identity, cost, and invocation pattern, with the core action front-loaded. 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 zero-parameter, no-output-schema sign-in tool, the description covers action, safety (no funds moved), and call relationships. Missing details are secondary: idempotency and effect on later calls.

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?

There are zero parameters and full schema description coverage, so the baseline of 4 applies. No additional parameter meaning is needed or expected 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?

The description states a specific verb and resource: signing in with the agent's own wallet and declaring agent status. It is clearly distinguishable from siblings like tokyo_read or tokyo_play, though it does not explicitly name an alternative to contrast against.

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?

"Other tools call it automatically when needed" gives clear operational context: in most flows the agent does not need to invoke this manually. It stops short of stating when manual invocation IS required or what prerequisites exist.

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 and discloses real behavioral traits: scoring scale (0–1000), a rate limit ('five attempts a day'), cost ('free'), and result semantics ('the best score counts'). It omits what happens on an invalid answer or whether sign-in is required, but covers more than most mutation tools.

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?

Front-loads the action, then the prerequisite, then the answer shape, then scoring rules — a sensible order with no filler sentences. The telegraphic format fragments (Loot/Courier/Ledger) are dense but each carries information the schema lacks.

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 one-param mutation tool with no annotations and no output schema, the description supplies the answer format, scoring, attempt limit, and best-score semantics. It is close to complete, missing only failure/error behavior and any auth precondition.

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% and the lone 'answer' parameter is a bare nested object, so the description must compensate — and it does, spelling out the expected shape: Loot {items:[indices]}, Courier {order:[1..8 in visit order]}, Ledger {top:'crew', balance:n, rejected:n}. Some fields remain cryptic (what the indices index, accepted 'crew' values), so it falls short of fully documenting the object.

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 ('Submit') and resource ('an answer to today's Tokyo Trials challenge'), and explicitly routes the agent to the companion read tool with 'read it first with tokyo_read what=trials'. An agent can tell this apart from the read sibling 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?

Gives a clear prerequisite and ordering ('read it first with tokyo_read what=trials'), which is exactly the context an agent needs before submitting. It does not, however, address alternatives like tokyo_play or state when not to use this tool.

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