Check a wallet's gm.ink agent status: registration, last GM timestamp, and whether the 24-hour cooldown has passed to know if it can GM now.
One-shot agent-GM snapshot for a wallet on gm.ink: whether it is a registered agent, its last agent-GM timestamp, and whether the 24h cooldown has elapsed (can it GM now?). Read-only, no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address to check |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description carries the full disclosure burden and meets it well: it explicitly declares 'Read-only, no key needed,' which tells the agent the operation has no side effects and requires no authentication. It does not describe the return format, but for a non-mutating status tool the side-effect and auth disclosures are the critical behavioral facts and are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence front-loading the core purpose ('One-shot agent-GM snapshot') and packing the three outputs, the cooldown question, and the read-only/no-key traits into a compact whole. Zero filler words; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only, single-parameter tool, the description is logically complete: it states what the tool returns, how to invoke it (a wallet address), that it is safe and auth-free, and even frames the business question it answers. Nothing an agent needs to select and call 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?
Schema coverage is 100% (the single 'address' parameter is fully documented in the schema). The description adds marginal semantic value by establishing 'for a wallet on gm.ink', which ties the address to a specific platform/domain context. This meets the baseline for a fully schema-covered single parameter but adds no syntax or 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?
States a specific verb+resource ('One-shot agent-GM snapshot for a wallet on gm.ink') and enumerates the exact facts returned: registration status, last GM timestamp, and whether the 24h cooldown has elapsed. This clearly differentiates it from the action-oriented siblings (gm_register_agent, gm_agent_gm) and the single-fact gm_agent_last_gm — it is the combined status view.
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?
'Read-only, no key needed' provides useful operational context, and the parenthetical '(can it GM now?)' signals the readiness-check use case. However, the description never explicitly names the sibling alternatives (e.g., gm_agent_last_gm) or states when to prefer this snapshot over them. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.