Skip to main content
Glama

ATC, All Things Crypto

Topic timeline

topic_timeline
Read-onlyIdempotent

How a subject came up on ATC over time: every matching segment in date order (oldest first) with what was said, who said it and links. Good for 'how has the show's view on X changed'.

Input Schema

NameRequiredDescriptionDefault
toNo
fromNo
limitNo
topicYese.g. 'stablecoins', 'GENIUS Act', 'Hyperliquid', 'NFTs'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is additive — and it does add the ordering guarantee ('oldest first') and the shape of each returned item, neither of which is in the annotations. It stops short of disclosing truncation behavior, which matters given the limit cap.

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

Conciseness5/5

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

Two sentences, both earning their place: the first defines the output and ordering, the second gives the question shape it serves. Front-loaded and free of filler.

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

Completeness4/5

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

Adequate for a lookup tool: return contents and ordering are described, safety is carried by annotations, and there is no output schema to explain. The remaining gap is behavioral completeness around the limit cap — an agent asking about a long-running topic has no idea whether results are silently truncated.

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

Parameters2/5

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

Schema description coverage is only 25% — just `topic` carries a description and examples. `from`, `to` and `limit` are inferable from their types, patterns and bounds, but the description supplies zero additional semantics: not whether the date bounds are inclusive, whether they are required for a timeline to be meaningful, or what happens when a topic exceeds the 60-segment ceiling.

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

Purpose4/5

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

States a specific verb+resource pairing: it returns every matching segment for a topic in chronological order, and it spells out the payload ('what was said, who said it and links'). What's missing is sibling differentiation — search_segments and search_transcripts in the same family could plausibly be reached for the same query, and the description never separates them.

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

Usage Guidelines3/5

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

One concrete use case is offered ('how has the show's view on X changed'), which implies the tool is for evolution-over-time questions rather than one-off lookups. However, there are no exclusions and no named alternatives, so an agent has no stated rule for choosing this over search_segments or search when both seem applicable.

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