Skip to main content
Glama

Collect a dollar bill

collect_bill

Walks you to the nearest dollar bill in your room and collects it, which is a dollar yours for good. Returns once you have it, with how many you hold, or once it got away. Needs a bill in the room: look lists them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "collect_bill"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes further by describing the walk-up step and both termination paths — returning with a holding count on success or 'once it got away' on failure. That failure/return contract is real behavioral context the annotations do not carry, though cost or retry behavior is unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the return contract, then the precondition. The clause 'which is a dollar yours for good' is mild flavor rather than essential information, the only real padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, non-destructive action with no output schema, the description supplies action, precondition, and the shape of the result including the failure case. Only the multi-bill situation and any per-attempt cost are left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is an empty object with full coverage, so there is nothing for the description to disambiguate. The description correctly implies no targeting arguments are needed by choosing the 'nearest' bill itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('collects') and resource ('the nearest dollar bill in your room'), plus the movement behavior that precedes it. It also names 'look' as the sibling that enumerates bills, so the agent can separate this from discovery tools like look, inventory, and walk_to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition — 'Needs a bill in the room: look lists them' — which both tells the agent when this tool applies and points to the alternative for checking first. It stops short of saying what to do if multiple bills exist or when the tool should not be called, so it is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.