Skip to main content
Glama

omnarai_trace

Read-only

Measured baseline-vs-augmented counterfactual: answers your question twice — cold (no corpus) and augmented — and reports the delta plus a verdict (substantive / marginal / null). Honest by construction. Runs as an async job (~35s): returns a job_id — poll with omnarai_job.

Input Schema

NameRequiredDescriptionDefault
questionYesThe question to trace with and without the corpus.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Goes well beyond the readOnly/openWorld annotations by disclosing the async execution model (~35s), that it returns a job_id rather than the result, and which tool to poll with. It does not mention cost, rate limits, or whether the cold answer incurs an extra model call, which keeps it from a 5.

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?

Front-loads the counterfactual definition, then the return contract (job_id, poll with omnarai_job) in a tight sequence. 'Honest by construction' is the only flourish and it is brief.

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?

With no output schema, the description correctly explains the return shape: job_id first, then delta and one of three verdicts. It lacks detail on what the delta is measured in (score points, tokens, latency), which is the one thing an agent interpreting results would still want.

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

Parameters3/5

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

Only one parameter with 100% schema coverage, so the schema already defines `question` fully. The description adds the useful nuance that the same question is run both with and without the corpus, but no format or length guidance beyond that.

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

Purpose5/5

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

States a specific operation: answer the question twice, cold vs augmented, and report the delta plus a verdict. It is clearly distinguishable from siblings like omnarai_query or omnarai_context, which retrieve rather than measure corpus impact.

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?

Usage is implied by the measurement framing (use it to test whether the corpus actually helps), but there is no explicit when-to-use, when-not-to-use, or named alternative such as omnarai_query for plain retrieval. The agent must infer the routing decision.

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.