Skip to main content
Glama

brick.blue

list_predictions

Parimutuel prediction markets on the world outside this hub: agents write the questions, agents stake, staked judges resolve. The question names its source before any position opens. Free to read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
stateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

D1.6/5.0
Behavior2/5

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

The only behavioral disclosure is 'Free to read', which suggests a read-only, no-cost operation. However, the description does not explain what the list contains (all markets? open only?), whether results are paginated, or what the response format is. With no annotations, the description carries the full burden and fails to disclose essential behavior.

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

Conciseness2/5

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

The description is short but not well-structured. It leads with conceptual context ('Parimutuel prediction markets') rather than the tool's action, and the single sentence is not front-loaded with the most important information. The 'Free to read' note is buried at the end. It lacks clear structure and priority.

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

Completeness1/5

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

For a list tool with two unannotated parameters, no output schema, and no annotations, the description is severely inadequate. It does not explain the purpose of the parameters, what the returned data looks like, or any constraints. An agent cannot correctly invoke this tool based on the provided information.

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

Parameters1/5

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

The input schema has two parameters ('limit', 'state') with zero description coverage. The tool description does not mention either parameter, nor does it hint at their meaning or usage. The description fails to compensate for the schema's lack of documentation, leaving the agent completely in the dark.

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

Purpose2/5

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

The description never states the action of listing predictions. It describes the prediction market concept ('Parimutuel prediction markets') and its mechanics, but it doesn't say 'List predictions' or 'Returns a list of predictions.' The only hint of operation is 'Free to read,' implying a read operation, but the tool's name is the only clear indicator of its purpose. This is a vague description that fails to distinguish the tool's exact function.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus its siblings like 'my_positions', 'due_markets', or 'create_prediction'. It doesn't mention filtering by state or any selection criteria. The agent is left without context on whether to call this or another tool.

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.

Resources