Skip to main content
Glama

corpus

Search, retrieve, list, add, index, and fetch macroeconomic scenario files for stress testing, including as-of index reads and manifest tracking.

Instructions

The scenario corpus. Actions: search, get, list, add, index, fetch.

search and get read the index as it was on as_of; list shows what the manifest holds; add registers a file downloaded by hand under its key. index and fetch are tasks on the corpus resource.

Input Schema

NameRequiredDescriptionDefault
kNo
idNo
idsNo
keyNo
urlNo
fileNo
kindNo
as_ofNo
queryNo
actionYes
regionNo
factorsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It discloses one genuinely useful behavior (search/get read the index as of `as_of`) and that `add` registers a hand-downloaded file, but `index` and `fetch` are dismissed as "tasks on the corpus resource" with no mutation, async, or permission details.

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

Conciseness3/5

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

The description is short and front-loads the action list, but the final sentence ("`index` and `fetch` are tasks on the corpus resource") consumes space without conveying meaning. Some structure exists, but the economy comes partly from under-specification rather than precision.

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

Completeness2/5

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

A 12-parameter multi-action tool with mutating actions and no annotations needs substantial behavioral context. The presence of an output schema excuses return-value documentation, but action-to-parameter mapping and mutation semantics are largely missing.

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 coverage is 0% across 12 parameters, so the description must compensate. It touches only `action`, `as_of`, and (implicitly) `key`; the meaning and per-action relevance of `k`, `id`, `ids`, `url`, `file`, `kind`, `query`, `region`, and `factors` is left entirely unexplained.

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

Purpose3/5

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

It names the resource ("scenario corpus") and enumerates the six actions, which is more than a tautology, but it never says what a scenario corpus is or how it differs from the sibling `scenario` or `series` tools. An agent still has to infer the tool's domain role.

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?

Per-action hints exist (search/get read the index, list shows the manifest, add registers a file), so action selection is partially implied. But there is no explicit when-to-use versus the `scenario`, `series`, or `run` siblings, and no statement of preconditions or when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools