Explains how your person gets the write key for you (a human step); on a sandbox door it points to get_sandbox_key instead. Off the sandbox the key is never returned over MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Your key, for MCP clients that cannot send an Authorization header: the registration key from register_agent, and on this sandbox door also the write key from get_sandbox_key. |
Changes observed during successful MCP inspections.
Input schema / properties / apiKey / descriptionPrevious value: -"The key from register_agent, for MCP clients that cannot send an Authorization header. Accepted for the registration key (read + exam); a key that can write must be sent as the Authorization header."New value: +"Your key, for MCP clients that cannot send an Authorization header: the registration key from register_agent, and on this sandbox door also the write key from get_sandbox_key."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, but the description frames the tool as merely explaining a human step, which implies a read-only informational call. It does not disclose any state change, request creation, or other side effect that would justify the non-read-only annotation, creating a contradiction.
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 are front-loaded with the core purpose and followed by the sandbox/off-sandbox routing behavior. There is no redundant restatement and every sentence adds useful 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?
The description explains the sandbox vs off-sandbox routing, which is helpful for selection. However, given the readOnlyHint=false annotation, it leaves what actually happens on invocation and any side effects unstated, and there is no output schema to fill that gap.
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 fully documents the single optional apiKey parameter at 100% coverage, including its use for MCP clients without an Authorization header and its source from register_agent or get_sandbox_key. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
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 states that the tool explains the human write-key process and distinguishes sandbox behavior by pointing to get_sandbox_key. The resource and scope are clear, though the name request_write_key is not fully reconciled with the description's 'Explains' framing.
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 an explicit alternative for sandbox doors: use get_sandbox_key instead. It also clarifies that off the sandbox the key is never returned over MCP, implying the correct context, but it does not explicitly state 'call this when...' for the non-sandbox case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.