Retrieve a stored authorization code (one-time read, auto-deleted).
Called by the originating MCP server to pick up the code after the user has authorized in the browser. Returns the encrypted code which the caller decrypts using the same state token.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The state token (patron npub) used during authorization. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / state / descriptionAdded value: +"The state token (patron npub) used during authorization."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the critical side effect ('one-time read, auto-deleted'), the return shape ('encrypted code'), and the decryption mechanism using the state token. This is strong behavioral disclosure for a simple retrieval 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 two tight sentences with no filler. The key behavioral qualifier is front-loaded in parentheses, and the context sentence adds necessary protocol detail without repeating the schema.
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 one-parameter tool with an output schema present, the description covers purpose, invocation timing, return value, and destructive one-time behavior. It is nearly complete; it omits only minor details such as error cases or what happens when the state token is invalid.
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 schema already fully documents the 'state' parameter. The description adds marginal value by noting the caller uses 'the same state token' for decryption, but it does not need to compensate for any schema 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 starts with a specific verb and resource — 'Retrieve a stored authorization code' — and adds a defining behavioral qualifier ('one-time read, auto-deleted'). It clearly differentiates this tool from the sibling status tools and from store_code, making its role unmistakable.
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: 'Called by the originating MCP server to pick up the code after the user has authorized in the browser.' This tells an agent when the tool is appropriate. It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for correct invocation.
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.
store_code and retrieve_code are an obvious complementary pair, and the two status tools target different concerns: pending authorization codes versus deployed build information. The shared _status suffix could cause a quick misread, but the descriptions make the boundaries clear.
store_code and retrieve_code follow a clear verb_noun pattern, while collector_status and service_status are noun phrases. Each subgroup is internally consistent, but the server as a whole mixes two naming conventions, so the next tool name is not fully predictable.
Four tools is well-scoped for this utility: the store/retrieve pair handles the OAuth2 flow, collector_status covers operational health, and service_status supports deployment verification. Each tool has a distinct job without bloat.
The core OAuth2 code lifecycle is covered end-to-end: codes can be stored, consumed once, and monitored via collector_status. Auto-deletion on retrieval and TTL-based expiry make an explicit delete tool unnecessary, and service_status fills the deploy-verification concern.