Skip to main content
Glama

MATCH, RUN, or EVIDENCE (run 0.0010); evidence is a hit without receipts

ask
Read-only

When to call: you have a question or a payload and want the cheapest verified step. MATCH lists program classes and pages (free without input). RUN executes one fixture program when the class is certain and input is present (¢0.1). Otherwise EVIDENCE: an answer stitched from verified quotes the library already holds, a hit (free within the daily allowance); receipts: true adds a Signed receipt per quote and is metered. Set allow_escalate only to send YOUR ask to YOUR engine. A miss names research/deposit with prices. An ask that starts with a research verb (research X, look up X, find sources on X) is step_taken=research: the topic, the mint price first, the research call to make and the pages already near it; the answer path is not asked. On a member node whose served model may talk, a plain ask no tool or page answers returns step_taken=talk: the model's own words under model (verified: false, never checked) plus actions the node validated; pass thread for earlier turns. Where its grounding switch is on that is step_taken=synthesis: the model's words written from the library's quotes, synthesis.sentences[] each with backed and the claim_ids that carry it (checked by word, not meaning).

Input Schema

NameRequiredDescriptionDefault
askYesThe question or task
inputNoPayload to run through a matched program
threadNoEarlier turns for TALK: [{who: person|model|library, text}]
class_idNoForce a program class when you already know it
receiptsNoA Signed receipt per quote on EVIDENCE (default false; with receipts the step is metered)
x_paymentNo
work_tokenNo
think_harderNoTALK with the model's thinking on and a longer budget
allow_escalateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / think_harder
      Added value: +{
      +  "description": "TALK with the model's thinking on and a longer budget",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / thread
      Added value: +{
      +  "description": "Earlier turns for TALK: [{who: person|model|library, text}]",
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / receipts
      Added value: +{
      +  "description": "A Signed receipt per quote on EVIDENCE (default false; with receipts the step is metered)",
      +  "type": "boolean"
      +}
  3. Added

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations, the description discloses costs (¢0.1, free daily allowance, metered receipts), escalation behavior, miss behavior naming research/deposit with prices, and output-shape differences for talk and synthesis. It does not directly contradict readOnlyHint=true, destructiveHint=false, or openWorldHint=false, though its dense mode logic leaves some operational edge cases unclear.

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

Conciseness2/5

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

The opening 'When to call' is front-loaded, but the definition becomes a long, dense paragraph with semicolon-chained conditionals and specialized vocabulary. The content is substantive, but the lack of structure and heavy nesting hurts readability and makes it hard to scan.

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 and nine parameters, the description carries significant burden and does explain key return paths such as step_taken values, model/actions, synthesis.sentences[].backed, and research/deposit miss behavior. It is fairly complete for a complex routing tool, though missing payment/work-token semantics and some conditional clarity keeps it from being fully complete.

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?

The description adds useful meaning for ask, input, class_id, thread, receipts, and allow_escalate, clarifying when each matters in the routing flow. However, schema coverage is 67% and parameters like x_payment and work_token remain undocumented in both schema and description, so it does not fully compensate for the gaps.

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?

The description explains several internal modes (MATCH, RUN, EVIDENCE, TALK, synthesis) but never states a single clear purpose beyond 'you have a question or a payload and want the cheapest verified step.' It implies an orchestration/query tool, yet the overloaded framing and cryptic title make it harder to distinguish from siblings like match and run_program.

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

Usage Guidelines5/5

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

It explicitly opens with 'When to call' and then gives concrete conditions for each mode: MATCH when listing classes/pages, RUN when the class is certain and input is present, EVIDENCE otherwise, research verbs routing to research, and TALK/synthesis on member nodes. It also names alternatives and constraints such as allow_escalate only for the caller's own engine.

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