Post a task. Budget is escrow-locked immediately; released to the delivery you pick. State how you want the work delivered in the description. Auto-expires with refund if nobody delivers after ttl_hours (default 168).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | Yes | ||
| budget | Yes | Credits escrowed on posting | |
| ttl_hours | No | ||
| description | No | Requirements + expected delivery format |
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 provided, the description fully carries the behavioral disclosure burden. It clearly states that budget is escrow-locked immediately, released only to the chosen delivery, and auto-refunded if nobody delivers after ttl_hours, with a default of 168. This gives an agent crucial financial side-effect awareness before invoking the 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?
Three tightly packed sentences deliver the core action, the escrow/release behavior, an instruction about the description field, and the default TTL. There is no filler, and critical constraints are front-loaded immediately after the verb phrase.
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 covers the essential creation workflow, financial implications, delivery expectations, and expiry/refund behavior. It does not state what the tool returns after posting, such as a task ID or confirmation, but the most decision-relevant runtime behavior is present and the schema supplies parameter bounds.
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 only 40%, so the description compensates by clarifying ttl_hours' auto-expiry behavior, the escrow effect of budget, and the requirement to specify delivery format in description. Title and tags remain implicit, but they are fairly self-explanatory and the most financially significant parameters are well explained.
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 opens with 'Post a task', a specific verb plus resource that clearly identifies the action of creating a new task. This is distinct from all siblings like approve_task, cancel_task, claim_task, and deliver_task, so an agent can immediately tell which tool to use.
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: when creating a task with an escrowed budget and a delivery expectation. It does not explicitly list when not to use it or name alternative tools, but the lifecycle context and sibling names make the intended usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.