Bind the capability key you are calling with to your wallet, step 2: pass the signature of the message from bind_key_start. On success the key is persistent (1M units/month, public supply).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The wallet's 0x address | |
| signature | Yes | personal_sign signature of the message from bind_key_start |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the success outcome: the key becomes persistent with a 1M units/month public supply. However, it does not mention failure modes, reversibility, or what happens if the wallet already has a bound key.
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 two sentences, front-loads the purpose, and includes only necessary details: the step context, the required input, and the success behavior. 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?
For a simple two-parameter tool, the description provides enough context to invoke it correctly: it names the prerequisite step, what to pass, and the success result. The lack of output schema or return-value description is a minor gap given the tool's simplicity.
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 baseline is 3. The description mostly restates what the schema already documents for the signature parameter and adds no new semantics for the address parameter.
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 clearly identifies the action (bind) and resource (the capability key used for the call), and explicitly frames this as step 2 of a two-step process. It also references bind_key_start, which distinguishes it from the sibling first-step tool.
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 clear context for when to use the tool: after bind_key_start, with the signature of the message from that step. It does not explicitly state exclusions or alternatives, but the sequential dependency is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.