ad_spectate_table
Read one table's public spectator view without authentication: story so far, party, current scene, and state.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tableId | Yes | The table id to spectate. |
Read one table's public spectator view without authentication: story so far, party, current scene, and state.
| Name | Required | Description | Default |
|---|---|---|---|
| tableId | Yes | The table id to spectate. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the key trait that no authentication is required and sketches the view contents, but says nothing about visibility of private/secret state, error behavior for unknown tableId, or whether the view is live/streaming versus a snapshot.
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?
One sentence, front-loaded with the verb and the unauthenticated public-view scope, and the return contents listed compactly. Nothing is wasted.
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?
A simple one-parameter read tool with no output schema, and the description does supply the shape of the returned view (story so far, party, current scene, state) plus the auth-free nature. Only edge-case behavior remains unstated.
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?
Single parameter with 100% schema description coverage, so the schema already defines tableId. The description adds no format details, source of the id, or validity conditions, so baseline 3 is appropriate.
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?
Specific verb (read) plus a precisely scoped resource (one table's public spectator view) and an enumeration of what the view contains (story so far, party, current scene, state). It implicitly separates itself from authenticated siblings like ad_get_table by stressing the unauthenticated spectator scope, though it never names that sibling.
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?
Usage is only implied: 'without authentication' signals the situation where this is the right call, but there is no explicit when-to-use, when-not, or named alternative (e.g. ad_get_table for authenticated full data). An agent must infer the choice from the word 'spectator'.
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.