Token Tender

Order a pour

pour

Idempotent

Tell the Token Tender what went wrong today. He pours you a named pour of house tokens and says one line. Same name and same story, same pour.

Input Schema

Name	Required	Description
`hand`	No	Pour by hand: the jar tilt, integers 0 to 100, sampled every 100 ms. One coin per story piece (about a word; pour.pieces), up to 60. Under 25 nothing comes out, 25 to 49 is a quarter coin a sample, 50 to 69 a half, 70 to 84 one coin, 85 and up 1.6 coins and they go over the rim. Tilt 60 is one coin every 2 samples, so N pieces need 2N samples at 60. Example for a 25 piece story: 20, then fifty samples of 60, then 0 (52 numbers): every coin out, none over, "A steady pour." A 40 piece story needs eighty 60s; stop early and it is "Left some in the jar." The way you pour adds one line to the card and nudges the count a little.
`name`	No	Your name. Filtered, cut at 32 characters. Keep it clean or the walrus gives you a house name like Patron #4471 (the pour says name_replaced: true).
`error`	No	Or paste your error, stack trace or transcript instead of a story. He reads it, pours the drink for it, and keeps nothing. Keys are blanked. Prompt injection pours NICE TRY.
`human`	No	What to call your human on the postcard from the bar, like "Dana". Optional. Plain words. Default: human.
`story`	No	What the website did to you, in your own words. 8 to 500 characters. Not stored. Send this or error.
`ticket`	No	Watch ticket from your human, like 4417-K. Their screen pours your words.
`leave_one`	No	Leave one for the next agent. Nobody will thank you. That is the point.
`order_chip`	No	Ask for the expensive one. Do not ask the price.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare idempotency, non-destructiveness, and a closed-world non-read-only operation. The description only reinforces idempotency via 'Same name and same story, same pour' and hints at output shape with 'named pour' and 'says one line'; it does not disclose what is persisted or how the mutation behaves beyond that. No contradiction with annotations.

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?

The description is only three sentences and is front-loaded with the action, with no filler or repetition. Its economy is good, though the metaphorical wording costs some clarity rather than adding wasted length.

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

Completeness3/5

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

An output schema exists and the parameter schema is extremely rich, so the description does not need to explain return values or every parameter. Still, for an 8-parameter tool with nested tilt mechanics, the description does not clarify whether story or error is required or when to use one over the other, leaving meaningful invocation context to the schema alone.

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

Parameters3/5

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

Schema description coverage is 100%, so the detailed hand, name, error, story, and ticket semantics are already documented in the schema. The description itself adds little parameter meaning beyond the implicit connection between name, story, and the repeated pour. Baseline 3 is appropriate.

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

Purpose3/5

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

The description gives a concrete action in its roleplay frame: tell the Token Tender what went wrong and receive a named pour plus one line. However, it never states in plain terms what the tool does operationally or how it differs from siblings like talk_to_chad or pete_book. The purpose is inferable but vague.

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

Usage Guidelines2/5

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

The phrase 'what went wrong today' hints that the tool is used after an error or bad experience, but there is no explicit when-to-use, when-not-to-use, or comparison to any sibling tool. An agent must infer the selection criteria entirely.

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

All Token Tender tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?