Skip to main content
Glama

record_evaluation

Destructive

Records whether a review round's evidence answers the research question; if gaps remain, it captures them and starts a revised search within the same review.

Instructions

Deep mode: record whether this round's evidence is enough; if not, the revised question is searched into the same review and the next round begins. Rules: guide("evaluation").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "run_id": "<run_id>",
      "sufficient": "<sufficient>",
      "assessment": "<assessment>",
      "gaps": "<gaps>",
      "adequate": "<adequate>"
    },
    "name": "record_evaluation"
  }
}

Input Schema

NameRequiredDescriptionDefault
gapsYesParts of the question still unanswered
run_idYesRun ID from start_search
adequateYesuids of the included studies that directly answer the question
questionNoWhen not sufficient and rounds are left: a revised search aimed at the gaps (guide('question')); omit otherwise
assessmentYes2-4 plain sentences for the report, citing studies as [uid]
sufficientYesWhether the included studies answer the question

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is partly covered. The description adds real value by disclosing the loop consequence — an insufficient verdict causes the revised question to be searched into the same review and a new round to begin — but never explains why the call is destructive or what state is consumed/altered beyond that.

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

Conciseness4/5

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

Two short sentences with no waste and the deep-mode scoping front-loaded. The second sentence is grammatically awkward ('the revised question is searched into the same review'), costing a little clarity.

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

Completeness3/5

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

Output schema and full parameter documentation mean return values needn't be described. Still, for a loop-control tool with destructive annotations, the description leaves the caller's prerequisites and the difference from sibling recorders (e.g. record_synthesis, next_synthesis) to inference.

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?

Schema description coverage is 100% with 6 well-annotated parameters (gaps, adequate, assessment, sufficient, question, run_id), so the schema carries the semantics. The description mentions the 'revised question' concept but adds no format, bounds, or conditional requirement detail beyond what the schema states.

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 (record) and resource (this round's evidence-sufficiency evaluation) and scopes it to deep mode, which separates it from screening/synthesis recorders. However, the phrasing 'record whether this round's evidence is enough' is loop-jargon that an agent must already understand to parse.

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?

'Deep mode' and the conditional 'if not... the next round begins' imply when this fires (end of each deep-mode round). No explicit exclusions or named alternatives are given; instead it defers rules to guide('evaluation'), which is a pointer rather than guidance in the definition itself.

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