pay_entry

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

With zero annotations present, the description fully carries the burden—and it delivers. It discloses real side effects (a financial charge 'pays the entry fee over a 402 challenge'), identity creation ('that payment births your account'), idempotency ('returns the same account'), and the one-wallet-per-kingdom constraint. It also tells the agent to save the returned api_key since it is 'your identity for every other tool,' plus the forward-looking consequence of pre-paying for 3 territory claims. Exceptionally candid for a mutation tool.

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

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

The description is dense (~160 words) for a zero-parameter tool, leading with the core action and following up with essential gotchas. Some thematic flavor ('pre-gong naming is legal') could be tightened, but every sentence carries operational weight—pricing, idempotency, the api_key warning, or next-step routing—rather than filler. Well structured for the complexity it documents.

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 tool, the description leaves nothing critical unstated: it identifies the return payload components (agent + api_key + kingdom), flags the security-critical action (save the api_key), handles the idempotency edge case, addresses the tournament/timing constraint, and routes to the next tool. There's no output schema to defer to, yet the agent is fully equipped to call and consume this correctly.

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

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

The schema has 0 parameters, so the baseline is 4 per the rubric. The description correctly focuses on the environment variable (CROWNS_WALLET_KEY in the MCP server env) that feeds the call, which is genuinely useful contextual setup information that the empty schema couldn't possibly convey. It isn't a 5 because there simply are no parameters to enrich, but the env-var detail earns full credit within its lane.

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 purpose: pay the entry fee and create the agent's identity (agent + api_key + kingdom). The opening metaphor 'Join the game' is immediately grounded with specifics, and the tool is clearly differentiated from the sibling register by explicitly stating 'After this, call register to name your kingdom.' An agent can unambiguously tell this is the entry/onboarding tool vs. the other 76 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?

Provides explicit orchestration: 'After this, call register to name your kingdom' tells the agent the next step, while 'calling again returns the same account (idempotent)' tells it when NOT to make a second call. The registration-window caveat ('pre-gong naming is legal; claiming opens at the gong') is exactly the timing nuance an agent needs. This explicitly covers when/why to invoke, surpassing mere implied context.

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