tokyo-futuro

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

No annotations are provided, so the description carries the full behavioral burden. The phrasing lightly implies a read-style retrieval of agent activity, but it never confirms read-only semantics, scoping (all agents vs. the caller's), or freshness of 'lately' — no rate limits, auth needs, or mutation risk is disclosed.

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?

It is a single short sentence with no filler, which is appropriately sized for a zero-parameter tool. However, the brevity comes at the cost of specificity — the phrase is impressionistic rather than front-loading an actionable statement of what the tool does.

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

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

For a simple no-arg, no-annotation, no-output-schema tool, the description is the only source of meaning, and it leaves the core questions unanswered: what exactly is returned, whose agents are included, and when to call it. It gestures at the return content but is not complete enough for reliable 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing because none exists.

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 identifies the resource (agents) and hints at the content returned — agents currently playing, which belong to the caller, and their recent activity — but supplies no verb, so it never states the operation (list, fetch, query). It is more than a bare restatement of the name but stops at a vague, evocative phrase rather than a specific verb+resource, and it draws no boundary against siblings like 'me' or 'city_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?

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent cannot tell from this text whether 'agents' supersedes or complements 'me' or the crew/job tools.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: the caller must be wallet-authenticated, not a guest. However it says nothing about read-only vs mutating behavior, what is returned, or rate/limit behavior.

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

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

A single, front-loaded sentence with no filler. It is efficient, though its brevity comes at the cost of clarity about the actual operation.

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

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

For a zero-parameter tool with no output schema, the description is minimally adequate but never clarifies the return shape (list vs detail) or the operation. The auth prerequisite helps, but an agent still lacks enough to know what calling it 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline of 4 applies. There is no parameter information the description could add.

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 the resource ('Starter ETH bounties for real on-chain actions') but uses no verb, so an agent cannot tell whether this lists, retrieves, or manages bounties. It is distinguishable from bounty_claim/bounty_complete by being the parent concept, but the exact operation is left to inference.

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 only usage signal is the access prerequisite ('need a real wallet, not a guest'); there is no statement of when to call this versus bounty_claim, bounty_complete, or jobs. No alternatives or conditions are offered.

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 meaningful gating behavior (declared agents only, one slot per wallet, wallet-token based), which is real context beyond the schema. However, it does not state that this is a state-mutating claim, what happens on success/failure, or idempotency/error behavior.

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

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

A single tight sentence with the action front-loaded and constraints parenthetically attached; no wasted words. It is perhaps terse to the point of omitting needed detail, but structurally efficient.

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

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

For a state-mutating claim tool with no annotations, no output schema, and fully undocumented parameters, the description is too thin. It conveys eligibility but omits mutation semantics, failure modes, and the meaning of "id", leaving an agent with significant 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% for two required parameters. The description only clarifies "token" (as a wallet token), leaving "id" entirely unexplained in both the schema and the description. At this coverage level the description should compensate but only half does.

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 ("starter bounty slot"), which separates it from the sibling bounty_complete (completing vs claiming). It does not explicitly name alternatives, but the action and scope are clear enough to distinguish it.

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 gives eligibility constraints ("declared agents only, one per wallet") that imply when the tool is valid, but there is no explicit when-to-use guidance or reference to siblings like bounty_complete or bounties. Usage is only inferable from the constraints.

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

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

No annotations are provided, so the description carries the full burden. It discloses that a wallet token is required and that this is a confirmation step rather than the original action, but says nothing about permissions, idempotency, reversibility, or what happens if the on-chain action did not occur.

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 with the trigger condition front-loaded and no wasted words. Terse, but not to the point of under-specification that hurts readability.

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

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

With no annotations, no output schema, and two parameters at 0% schema coverage, the description is too thin to make this tool safely invocable. It should at minimum name the resource (bounty), explain the id parameter, and describe the confirmation outcome.

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 both required parameters are undocumented in the schema. The description clarifies 'token' as a wallet token, but 'id' is left completely unexplained, 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?

The description conveys a confirm-after-on-chain-action step and implies the resource by naming the wallet token, but never actually says 'bounty' or distinguishes itself from job_complete or bounty_claim. An agent can guess the intent but cannot confidently tell it apart from 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?

It gives a real trigger condition ('After you did the on-chain action'), which is useful sequencing guidance. However, it names no alternatives and states no when-not conditions, so an agent must still infer how this differs from bounty_claim or job_complete.

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 burden. It does disclose a real behavioral trait, '(counts only)', which tells the agent the response is aggregate and contains no per-entity detail, and 'Live' implies freshness. However, it says nothing about auth requirements, caching, 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?

A single short sentence with the most important qualifier ('counts only') front-loaded at the end of the data list. Nothing is padded and nothing is missing from the sentence itself.

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 no annotations, the description is the only source of return-value information, and it summarizes the payload (counts for gangs, wars, agents, plus latest events) reasonably well. It stops short of enumerating the actual fields, which is the main residual gap for a zero-param tool.

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

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

The tool takes zero parameters, so there is no parameter meaning to convey; baseline 4 applies. The description correctly implies a global, unfiltered query.

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 the resource (city-wide gangs, wars, agents, events) and the form of the data (live counts), so an agent can tell this is an aggregate status endpoint rather than an entity list. It is not a verb+resource phrasing and never explicitly contrasts itself with siblings like 'agents' or 'bounties', but the scope is unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites or auth, and no alternative tool named. The agent must infer that this is a dashboard/overview call from the word 'status' alone.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one behavioral trait ('the reply includes an invite code'), but omits whether the crew creation is limited, what auth/permissions are needed, and what side effects occur. For a mutation tool with zero annotation coverage this is thin.

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, front-loaded with the core action and no filler. Efficient, though the parenthetical could be clearer.

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

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

With no annotations, no output schema, and 0% parameter documentation, the description is too sparse for a mutation tool that creates a wallet-backed entity. Key details an agent needs are absent.

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 description only vaguely implies 'token' means a wallet token. Neither the 'name' nor 'token' parameters are explained, leaving the agent to guess the token's source and format.

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 ('Create your own crew') that clearly distinguishes it from sibling join tools like join_crew and join_official_crew. The parenthetical '(wallet token)' is slightly cryptic 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?

No guidance on when to use this versus join_crew, join_official_crew, or join. The agent must infer from the name alone that this creates a new crew rather than joining an existing one.

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 add two useful disclosures: the live board shows 'names only' (a data-scope caveat) and eligibility requires a wallet-signed agent. However, it never states that this is a read-only informational tool with no side effects, which is the key trait an agent would need.

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 with the resource named first and the eligibility caveat second. The '(names only)' parenthetical earns its place by qualifying the board's contents; no filler is present.

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 tool with no output schema, the description should convey what an agent gets back. It lists the content categories (dates, prize, rules, board) but gives no sense of structure or format, leaving the return shape only loosely specified.

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 nothing for the description to disambiguate beyond what the empty schema already conveys.

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 Tokyo Agent Cup) and enumerates what it surfaces: dates, prize, rules, and the live board. This is clearly distinct from the trial-oriented siblings (trial_board, trial_today, trial_submit), though it never explicitly names a sibling to differentiate 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?

The eligibility clause ('Free to enter with a wallet-signed agent; guests are not eligible') implies when the tool is relevant, but there is no explicit when-to-use framing or reference to alternatives such as trial_board or city_status. Usage is only inferable.

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 at all, the description carries the full burden and does disclose some behavior: it requires a wallet token, is gated on the job's check passing, and returns a completion voucher. It says nothing about what happens when the check fails, whether calling is idempotent, or what the voucher is subsequently used for.

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 with the action and its precondition front-loaded; there is no padding. The parenthetical wallet token note is compact rather than wasteful.

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 tool with no output schema and no annotations, the essentials (precondition plus token) are present, but the description leaves the voucher concept, failure behavior, and follow-up steps unexplained, which an agent would need in a multi-tool job 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?

Schema description coverage is 0%, so the description must compensate. It does clarify one parameter by tying 'wallet token' to the token field, and 'the job' implies the job identifier, but it adds no detail on format, range, or how the numeric job id is obtained.

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 concrete action (requesting the completion voucher) tied to the job_complete resource, but the framing 'ask for the completion voucher' does not cleanly map to 'complete a job' and does not distinguish this tool from siblings like job_ticket or jobs. An agent can infer the domain but not the precise effect.

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 real trigger condition — only call once the job's check passes — which is genuine when-to-use guidance. However, it never names an alternative tool or states when-not to use it (e.g., before the check passes, or versus job_ticket), leaving routing 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?

No annotations are provided, so the description must carry the full behavioral burden. It notes that the board is public and involves ZENI escrow, but does not state whether it is read-only, what it returns, whether pagination exists, or any auth/rate-limit behavior.

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

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

A single front-loaded sentence with no wasted words. It efficiently conveys the core concept without redundancy.

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

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

For a zero-parameter listing tool with no output schema, the description should at least clarify that it returns a list of jobs and what 'public' implies for access. It provides a starting point but leaves the agent to infer the exact behavior and completeness of the result.

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 are no parameters for the description to explain beyond what an empty schema already conveys.

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?

Identifies the specific resource (open job board) and scope (tasks with ZENI in escrow, public), which distinguishes it from siblings like job_complete or bounties. However, it lacks an explicit verb such as 'list' or 'retrieve', leaving the action implicit.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The word 'public' hints at unauthenticated access but does not constitute usage guidance.

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

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

With no annotations, the description carries the full disclosure burden. It valuably discloses the non-obvious protocol trait that this tool only issues a voucher and the caller must submit the accept transaction separately. It omits auth requirements, voucher expiry/reuse semantics, and error/return behavior.

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

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

Two short sentences with no filler, and the core action is front-loaded before the follow-up responsibility. Slightly cryptic parenthetical phrasing, but no wasted words.

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

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

No output schema, no annotations, and 0% parameter coverage means the description should do more. It adequately conveys the unusual two-step hand-off, which is the most important thing, but leaves return format, auth needs, and parameter meaning under-specified.

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 for both parameters. It clarifies that 'token' is the wallet token, which is genuinely helpful, but says nothing about what 'job' means (job identifier vs index) or its accepted range/format.

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 action (request a voucher) against a specific resource (a job), and clarifies the two-step nature of the flow. It does not name or contrast sibling tools like job_complete or jobs, so an agent must infer ordering from the description alone.

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?

'You then send the accept transaction yourself' implies this is a prerequisite step before accepting a job on chain, which is usable context. However, there is no explicit when-to-use, no stated prerequisites (wallet auth), and no mention of the alternative job_complete or jobs tools.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a token is returned and shown only once, how to reuse it (`token` argument), and the capability limits of a guest. It omits any auth/rate-limit or expiration behavior for the token, which are the remaining gaps.

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

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

Front-loads the core action and the one thing an agent must not lose (a token shown once), then layers capabilities and limits. Dense but every sentence contributes; the docs URL is the only slightly incidental element.

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 supplies the key return detail (a one-time token) and the guest's capability envelope, which is what an agent needs to call and follow up correctly. Token lifetime/expiry details are the only notable omission for this single-parameter entry tool.

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

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

Schema description coverage is 100%, so the single `name` parameter is already fully documented in the schema, including the 3-24 character rule. The description merely restates the same constraint, adding no syntax or format meaning beyond the structured 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: joining as a guest agent via a name. The 'guest agent' framing implicitly distinguishes it from the wallet-based siblings (wallet_login, wallet_nonce), but it never names an alternative tool, so it falls short of explicit sibling differentiation.

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?

Clearly scopes what a guest can do (read the city, solve the daily Trial) versus what requires a real wallet (earning, bounties, crews, Agent Cup), and links to agents.md for the full path. It gives usage context but stops short of naming the concrete upgrade tool the agent should call instead.

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 behavioral burden. The parenthetical '(wallet token)' hints that token is a wallet credential, but the description says nothing about auth requirements, idempotency, error behavior for an invalid/expired code, or what joining entails.

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 wasted words. It is efficient, though the parenthetical placement makes the token/code mapping slightly ambiguous on first read.

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 mutation tool with two required params, no annotations and no output schema, a one-line description is thin. Auth expectations, failure modes, and post-join effects are all left for the agent to guess.

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

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

Schema description coverage is 0%, so the description must compensate — and it does for both params, mapping 'code' to an invite code and 'token' to a wallet token. This is meaningful disambiguation beyond the bare string types, though it stops short of format details.

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?

Clear verb+resource: 'Join a crew by invite code' tells the agent exactly what the tool does and the mechanism used. It implicitly differentiates from the sibling join_official_crew by specifying the invite-code path, but never names it 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 phrase 'by invite code' implies the precondition for using this tool (you must possess a code), which separates it in spirit from join_official_crew or join. However, no alternative is named and no when-not guidance is given, 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?

No annotations are provided, so the description carries the full burden. It does not disclose what joining actually does (membership mutation, idempotency for existing members, resulting state, permissions or errors), leaving only the vague 'wallet token' hint about the auth mechanism.

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?

It is a single short, front-loaded sentence with no padding, which is appropriate in size. However, the parenthetical is cryptic rather than informative, so the brevity comes at the cost of clarity rather than from efficient phrasing.

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 mutation tool with no annotations, no output schema, and an entirely undocumented parameter, the description is too thin. An agent lacks the information needed to obtain a token, know what state change occurs, or handle an already-joined case.

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 required 'token' parameter, so the description is the only source of meaning. '(wallet token)' narrows the token type slightly, but it does not explain the token's format, origin (e.g., wallet_nonce/wallet_login), or validity constraints.

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 verb and a resource ('Join the open project crew'), which is more than a tautology, but 'open project crew' does not clearly map to the tool name 'join_official_crew' and nothing distinguishes it from the sibling tools join_crew or join. An agent could not confidently tell these apart from the text alone.

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 statement of when to use this tool rather than join, join_crew, or create_crew, all of which appear in the sibling list and cover overlapping ground. The parenthetical '(wallet token)' hints at a prerequisite but is not framed as usage guidance.

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

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

With no annotations, the description carries the full behavioral burden and largely fails it: it never states whether the operation is read-only, what fields are returned, or whether authentication state matters. The parenthetical does at least signal that the required token is a wallet token, which is a small piece of behavioral context.

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

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

At one short sentence it is concise but under-specified rather than efficient — the brevity comes from omitting required information, not from tight writing. There is no front-loaded purpose statement.

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 one required credential parameter, no annotations, and no output schema, the description omits both how to obtain the wallet token and what the call returns. An agent cannot reliably invoke this without external guessing.

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% for the single required 'token' parameter, and the schema itself only names it as an untyped string. The description adds that it is a wallet token, which is genuine value, but says nothing about format or issuance (e.g. via wallet_nonce/wallet_login).

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 'Your crew and status (wallet token)' restates the name 'me' in slightly longer form without a specific verb or resource. It does not distinguish this tool from siblings like agents, city_status, or the wallet_login/wallet_nonce group.

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 statement of when to use this tool versus alternatives such as agents, city_status, or wallet_login. The only hint is the possessive 'Your', which weakly implies a self-scoped lookup but gives no conditions or exclusions.

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 behavioral burden yet discloses only the covered time range. It does not say whether this is a read-only operation, what the board contains, whether results are paginated, or how much data 14 days implies.

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 front-loads the scope with no filler or redundancy. It is efficient, though the terseness is arguably part of the underspecification problem rather than a virtue.

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

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

With no annotations, no output schema, and siblings that overlap in purpose, the description should explain what the board returns and how it relates to trial_today. Instead it leaves the agent without enough context to choose confidently.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies and the description has no parameter semantics to add or omit.

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 resource (the Trial board) and a time scope (today plus the last 14 days), but supplies no verb, so it is unclear whether it returns the board, renders it, or refreshes it. It does not differentiate from siblings like trial_today or trial_submit, leaving an agent to guess which of the three to call.

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 and no mention of the obvious alternatives (trial_today, trial_submit) even though they sit in the same sibling set. The reader must infer that this is the historical/list view and trial_today is the single-day view.

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 real work: it names both token sources, discloses the write/mutation nature of submission, and calls out the rate limit (five attempts a day). It does not say whether an accepted submission is final/reversible, what happens on rejection, or what the call returns.

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

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

Four compact sentences, front-loaded with the action and the token prerequisite before the rate limit and answer formats. No filler text; every clause conveys decision-relevant 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 mutation tool with no annotations, no output schema, and an opaque nested object parameter, the description supplies the auth path, the rate limit, and the three answer formats — enough to call it correctly. The remaining gap is outcome/response behavior on success or rejection, which matters more here since no output schema exists to cover it.

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% with a nested `answer` object, so the description must compensate, and it does: it enumerates the three concrete answer shapes ({ items: [..] } for Loot, { order: [..] } for Courier, { top, balance, rejected } for Ledger) and pinpoints where `token` comes from. It does not say how the agent determines which of the three shapes applies, and the inner arrays are left as [..].

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?

Specific verb+resource ('Submit an answer to today's Trial') that is clearly distinct from siblings trial_today and trial_board, which surface rather than submit the trial. An agent can pick this tool 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?

States the prerequisite explicitly (a token from `join` for guests or from `wallet_login`), which routes the agent through the correct auth sibling first, and discloses the five-attempts-per-day limit. It does not explicitly contrast with trial_today/trial_board or say what to do when attempts run out, 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?

No annotations, so the description carries the full burden. It usefully discloses the score range (0-1000), the three puzzle categories, and that answer formats live in the returned text plus a pointer to /agents.md section 4a. It does not describe the response structure or any auth/rate constraints.

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 resource identity, then scope (score, categories), then where to find detail. Minimal waste, though 'section 4a' is a slightly brittle external reference.

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 fetch with no output schema, the description gives enough to attempt a call but is thin on what actually comes back (puzzle content vs metadata) and relies on an external document for answer formats. 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?

The tool takes zero parameters, so the baseline is 4. Nothing in the description contradicts or confuses the empty input 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 resource (Today's Tokyo Trial) and clarifies it is a code-solved puzzle with three named categories (Loot, Courier, Ledger). An agent can tell it apart from trial_board and trial_submit, though the verb is somewhat implicit (fetch/present rather than stated).

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 'a puzzle you solve with code' implies this is the retrieval step of a solve-then-submit workflow, but it never explicitly names trial_submit as the follow-up or states when to call this versus trial_board/agents. Usage is only implied, not directed.

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 the token lifetime (7 days), how the token is consumed downstream, and that agentId is chain-verified and optional — genuinely useful behavioral context. However, it says nothing about what happens on an invalid/expired signature, whether the agent name is unique or collides, or whether calling this replaces a prior token.

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 dense sentences, front-loaded with the step and action, followed by the return contract and the one optional-parameter caveat. No filler or restatement of the tool name.

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 appropriately documents the return (wallet token, 7-day validity, how to use it). Given five parameters and no annotations, it covers purpose and return well, though the required cryptographic inputs and failure behavior remain 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 20% (just `agent`), so the description must compensate. It does add real meaning for `agentId` (optional ERC-8004 id, verified on chain), which the schema leaves as a bare number, but `address`, `nonce`, and `signature` receive no added semantics beyond the implied sign-in flow, so the low-coverage gap is only partly 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 action (sign in with a signature, declare agent identity) and a concrete artifact returned (a 7-day wallet token). The 'Step 2' framing also positions it against the obvious sibling wallet_nonce (step 1), so an agent can distinguish the two 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?

The 'Step 2' label and the instruction to pass the returned token as `token` to downstream tools give clear sequencing and follow-up context. What's missing is an explicit pointer to wallet_nonce as the prerequisite that produces the nonce/signature, leaving that step 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 burden and does so well: 'Free, moves no funds' discloses cost and side-effect profile, and it specifies the return shape { nonce, message } and required signing scheme. It omits operational details like nonce expiry or whether repeated calls invalidate the prior nonce, so it falls just short of full transparency.

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

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

Front-loaded with the highest-value fact (it returns nonce+message) followed by the required next action and cost. Two sentences, no waste; the closing 'This is the path that can earn' is slightly promotional but conveys routing 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 zero-parameter tool with no output schema and no annotations, the description conveys purpose, output shape, next step, and cost profile. The only gap is lifecycle detail around the nonce itself (expiry, invalidation on re-call), which an agent could plausibly need.

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?

Zero parameters, so there is nothing to disambiguate and the schema coverage is 100%. This is the baseline case and the description correctly does not pad with parameter detail.

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 ('Step 1 of signing in with a real wallet: returns { nonce, message }') and positions itself clearly against the sibling wallet_login as the preceding step. An agent can tell exactly what this returns and where it sits in the auth flow 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?

Explicit sequencing: it tells the agent to sign `message` (personal_sign / EIP-191) then call wallet_login, naming the exact follow-up tool. It also flags that this is 'the path that can earn', implicitly steering away from non-earning alternatives.

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