Skip to main content
Glama

ai: GET /api/ai/find-changes/progress

get_ai_find_changes_progress_fb6c87594c8171c59a792746
Read-onlyIdempotent

GET /api/ai/find-changes/progress. GET /api/ai/find-changes/progress. Operation ID: fb6c87594c8171c59a792746; describe_operation provides native request schemas.

Input Schema

NameRequiredDescriptionDefault
queryNo
paramsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context of its own — nothing about whether the progress is polled, what state it reports, or how a job id is obtained.

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?

Short, but the first two sentences are byte-identical duplicates of the route, and the 'Operation ID' string is internal noise rather than information. Not front-loaded with anything an agent can act on.

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?

This is a progress-polling endpoint on an AI job with a nested, wholly undocumented schema and no output schema, yet the description explains none of the return shape or polling semantics. Pointing at describe_operation is the only completeness gesture and it leaves a significant gap for a tool an agent would need to poll correctly.

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 description coverage is 0% across two free-form objects (query and an empty params), so the schema explains nothing. The description does not compensate at all — it only redirects to describe_operation, leaving the agent to make a second call to learn anything about inputs.

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

Purpose2/5

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

The description merely repeats the HTTP route 'GET /api/ai/find-changes/progress' twice, which is a restatement of the tool name rather than a plain-language statement of what the tool does. It never says in words that this returns the progress/status of an AI find-changes job, nor differentiates it from siblings like get_ai_find_changes_full_abstract_jobs or get_ai_extract_progress_by_jobId.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative among the many AI find-changes siblings. The only directional hint is 'describe_operation provides native request schemas', which points to a schema-discovery tool rather than explaining when this tool applies.

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