Create a USDC-on-Base charge for a real-world merchant. Returns the charge + the EIP-681 payment URI your OWN wallet must execute (basetill holds no key, moves no funds).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | merchant 0x address (their own wallet — non-custodial) | |
| label | No | ||
| orderId | No | ||
| amountUsd | Yes | e.g. "4.50" |
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?
Discloses that basetill holds no keys and moves no funds, which is critical for a payment-related tool. Also states that it returns a payment URI. With no annotations, this is good behavioral context, though could mention side effects or state changes.
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 sentences, front-loaded with key action and details. No extraneous information; every word earns its place.
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?
Explains what the tool returns (charge + payment URI) and the non-custodial nature. Lacks details on error cases or return format, but sufficient for an agent to use the tool correctly.
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 50%, and description adds only modest value: repeats schema for 'to' and gives an example for 'amountUsd', but provides no insights for 'label' and 'orderId'. Partially compensates for coverage gap but not fully.
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?
Clearly states the action (create) and resource (charge) with specific details (USDC-on-Base, real-world merchant). Distinguishes from siblings like till_create_invoice by specifying it's for charges and is non-custodial.
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?
Provides guidance that the user's own wallet must execute the payment URI, implying the tool is used when you want to initiate a payment request. Does not explicitly list alternatives or when not to use, but context with siblings provides implicit differentiation.
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.
Many tools have distinct, well-named purposes (vet_agent vs vet_merchant), but there is notable overlap between till_trust and till_vet_merchant (both provide trust verdicts), and till_launch_funder vs till_funder_history are closely related. The descriptions are detailed enough to differentiate, but an agent could still misselect between a few pairs.
All tools share the till_ prefix, but the pattern is mixed: some use verb_noun (check_invoice, create_charge, watch_wallet) while others are noun phrases (key_exposure, open_approvals, rug_powers) or bare nouns (floor, trust, roll). This is readable but not predictable, so an agent cannot reliably guess a tool name from a verb.
At 29 tools, this server exceeds the 25+ threshold that signals an overgrown toolkit. Even with a broad domain, many tools are one-off niche scanners (till_b20_authentic, till_floor, till_meter) that inflate the surface and could be consolidated or externalized.
The toolkit covers the payment lifecycle comprehensively: create charges/invoices, check payments, verify delivery, generate receipts, rolls, and accounting exports. It also spans identity, trust, security scanning, and theft tracing. Minor gaps exist (no update/cancel for charges, no token-general vetting), but the non-custodial, read-only design makes these acceptable.