Reads events from a purchased markets.stream ticket for up to 60 seconds and returns the events plus the last event ID for resuming.
Read events from a purchased markets.stream ticket for up to 60 seconds (free; the ticket was paid). Returns the events and the last event id to resume from.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | Yes | ||
| seconds | No | ||
| maxEvents | No | ||
| lastEventId | No |
Changes observed during successful MCP inspections.
v0.5.1Does 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 60-second blocking ceiling, that the call itself is free because the ticket is prepaid, and that resumption state is returned — but says nothing about what happens on timeout with zero events, whether the call blocks, or failure modes.
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?
A single tight sentence with the core action and scope front-loaded; the '(free; the ticket was paid)' parenthetical earns its place by removing cost uncertainty. Minor redundancy in restating the 60-second maximum already encoded in the schema.
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?
The return values are briefly characterized (events plus last event id), which is necessary since no output schema exists. However, for a long-poll style tool with no annotations and undescribed parameters, the definition leaves an agent guessing about timeout semantics, polling expectations, and maxEvents.
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 description coverage is 0% across 4 parameters, so the description must compensate. It gives meaning to three of them: ticket (must be a purchased/paid ticket), seconds (bounded by the 60s cap and tied to the free-read model), and lastEventId (resume point via the returned last event id). maxEvents is never mentioned, and the ticket string format is left entirely to the caller.
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+resource: 'Read events from a purchased markets.stream ticket.' The resource name is distinctive enough that an agent can separate it from tolly_alerts_read or tolly_jobs_search, though it never names those siblings explicitly.
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?
Implies prerequisites (a ticket must already be purchased/paid) and a hard time cap, which hints at when this is appropriate. But there is no explicit guidance on when to choose this over tolly_alerts_read or tolly_routed_search, and no 'when not to use' or error-condition guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.