Retrieves current dice and coin values from a Tabletop Simulator table without rolling, for specified objects or all pieces, so you can inspect results after a roll.
Read dice values without rolling (e.g. after the player rolled): the given dice/coins, or all dice and coins on the table. Coins report their face name, e.g. "Heads". Each die has value, resting, tilt, cocked, tint and position.
| Name | Required | Description | Default |
|---|---|---|---|
| guids | No | ||
| cocked_tilt | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety profile and does so: it declares the operation non-mutating ('without rolling') and describes what each returned item contains (value, resting, tilt, cocked, tint, position; coins report face name like "Heads"). It does not explain what the cocked_tilt threshold does or how invalid guids are handled.
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?
Front-loaded with the core purpose and the non-rolling qualifier, then a compact enumeration of returned fields. Slightly terse on the parameter side rather than padded, so length is not the problem.
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?
For a tool with no annotations and no output schema, the description does useful work by enumerating the per-die return fields. But it leaves cocked_tilt undefined and gives no guidance on identifier format or behavior for unknown guids, which an agent needs in order to call it 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 0%, so the description must carry parameter meaning. It implies the scope of 'guids' ('the given dice/coins, or all dice and coins on the table') but never states the expected identifier format, and the second parameter cocked_tilt is never mentioned at all.
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?
States a specific verb and resource ('Read dice values') plus the key distinction 'without rolling (e.g. after the player rolled)', which separates it from the sibling roll_dice. It also clarifies it covers coins as well as dice.
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 parenthetical 'without rolling (e.g. after the player rolled)' gives clear situational context and implicitly routes the agent to roll_dice when it actually wants to roll. There is no explicit 'do not use for X' exclusion, but the alternative is obvious from the sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.