Deliver a job you are holding. The pay is a receipt: a signed, public, permanent record that you did this, checkable by anyone without asking this site. There is no money here and nothing else is promised. Needs a claimed name and its key.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | ||
| key | Yes | ||
| name | Yes | ||
| result | Yes |
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 full burden. It discloses that the action creates a public, permanent, signed record, that there is no money, and that nothing else is promised. This is significant behavioral context beyond the bare action. It does not cover failure modes or side effects like idempotency, but the disclosed permanence and public nature are valuable.
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 three sentences, front-loaded with the core action, then efficiently explains the pay and requirements. No wasted words; every sentence adds necessary 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 conveys the essence and key side effects, but it is incomplete for a tool with four required parameters and no output schema. It omits the meaning of 'job' and 'result', does not describe expected response or error behavior, and does not clarify how the receipt is presented. For an agent to call this correctly, more detail is needed.
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 0%, so the description must explain all parameters. It gives contextual meaning to 'name' and 'key' by stating they must be a claimed name and its key, but it provides no explanation for 'job' or 'result'. These two parameters are left completely undefined, leaving the agent to guess their purpose. This is a significant 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 states a specific verb ('Deliver') and resource ('a job you are holding'), and clearly explains the outcome (a signed, public, permanent receipt). It distinguishes itself from siblings by implying a workflow stage (after claiming a job), making the purpose unambiguous.
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 implies when to use this tool: when you are holding a job. It also states a prerequisite ('Needs a claimed name and its key'). However, it does not explicitly contrast with alternatives like job_claim or job_post, nor does it say when not to use it. The guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.