get_regime_segmentsCompressed dealer-regime segment tape for one replay date (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Replay date in YYYY-MM-DD; use list_history_dates for the set of valid dates. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile: readOnlyHint is true, idempotentHint is true, and destructiveHint is false, so the agent knows this is a safe read. The description adds 'compressed' as an output trait, but it does not disclose pagination, missing-date behavior, or the structure of the returned tape; this is acceptable but not rich context.
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, front-loaded sentence that conveys the resource, the compression aspect, and the date scope without filler. The date format parenthetical is mildly redundant with the schema but does not undermine the overall efficiency.
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 one-parameter, read-only tool, the schema and annotations cover a lot of the burden. However, there is no output schema, and the description does not explain what a 'regime segment tape' contains, how to interpret it, or how it differs from the similar get_regime sibling, leaving some ambiguity for an agent.
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 100%: the date parameter already has a pattern, format, and a pointer to list_history_dates for valid values. The main description re-states the YYYY-MM-DD format but adds no substantial meaning beyond the schema, so the 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?
The description identifies a specific resource—a compressed dealer-regime segment tape—for a single replay date, so an agent can infer the tool's fetch operation. However, it does not explicitly contrast with the sibling get_regime, leaving the agent to rely on the phrase 'segment tape' for differentiation.
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 description implies when to use the tool: when you need the dealer-regime segment tape for one replay date. It provides no explicit when-not guidance or comparison to sibling tools like get_regime or get_day, and the only alternative-related signal (use list_history_dates for valid dates) lives in the schema rather than the description.
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.
Most tools have clearly distinct purposes, but get_regime is a lightweight subset of get_market_structure, and get_day versus get_regime_segments both target historical replay data with different granularity. Descriptions are clear enough to prevent serious misselection, though some overlap exists.
Tool names consistently follow a verb_noun pattern: get_* for data retrieval, list_* for enumeration, subscribe_*/unsubscribe for lifecycle actions. The naming is predictable and scannable across the whole set.
Nine tools is well-scoped for this server's purpose: current market structure, regime snapshots, historical replays, a field guide, and subscription management. Each tool occupies a clear functional slot without unnecessary bloat.
The surface covers the core domain completely: current data, lightweight regime checks, historical date discovery and replay, field semantics, and full event-subscription lifecycle. No obvious dead ends or missing operations for the stated purpose.