Skip to main content
Glama

exam_loop_progress

Reads exam loop progress for a specified run ID without opening or changing a browser page, letting you check status and continue study workflows without disturbing the active session.

Instructions

Read loop progress without opening or changing any browser page.

Input Schema

NameRequiredDescriptionDefault
run_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.4

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the key trait: this is a pure read that neither opens nor mutates a browser page. Beyond that it says nothing about whether a run must be active, what happens with an unknown run_id, or any rate/session constraints.

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?

One short, front-loaded sentence with no filler and the read-only guarantee stated up front. Its brevity is efficient, though it brushes against under-specification given the undefined term 'loop'.

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?

An output schema exists, so return values needn't be explained, but the definition still leaves the required run_id undocumented and provides no basis for choosing between this and the several overlapping progress/read siblings. For a tool in a crowded exam-progress namespace, that is a substantial gap.

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% and the single required parameter run_id has no description in either schema or description. The description could have clarified what a run_id identifies and where to obtain it, but adds no meaning beyond the parameter name.

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 verb 'Read' and object 'loop progress' are stated, but 'loop' is undefined jargon and the definition never says which loop (exam question loop?) or what progress means. It also fails to distinguish itself from close siblings like exam_browser_progress and get_exam_progress, which sound like they read similar state.

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

Usage Guidelines2/5

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

The only usage signal is the negative constraint 'without opening or changing any browser page', which hints at a lightweight read path. There is no stated condition for choosing this over exam_browser_progress or get_exam_progress, and no prerequisites or preconditions for run_id.

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