Skip to main content
Glama

drift_check

[trust] DriftGuard check (DRG-100-DriftBound)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
current_windowYes
reference_windowYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

D1.3/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no cost, permissions, whether it mutates state or merely reports, rate limits, or what happens when the windows don't overlap. The '[trust]' tag and 'DRG-100-DriftBound' code are opaque labels, not behavioral information.

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?

It is short, but its brevity comes from under-specification rather than efficiency — a single fragment that communicates no operation. There is nothing to front-load because nothing substantive is said.

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

Completeness1/5

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

For a tool with a nested-object schema, three required params, no output schema, and no annotations, the description should carry the entire explanatory load. It provides none of it, so the agent cannot construct a valid or meaningful call.

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

Parameters1/5

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

Schema description coverage is 0% across three required parameters, two of which are nested objects (reference_window, current_window) with entirely undefined shape. The description adds no meaning to model_id or the window structures, leaving their format, units, and expected keys completely unspecified.

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 says 'DriftGuard check (DRG-100-DriftBound)', which essentially restates the tool name inside a product codename plus an undocumented internal identifier. It never explains what 'drift' means here or what the check measures, so an agent cannot distinguish it from siblings like drift_certificate or agents_semantic_diff.

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

Usage Guidelines1/5

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

No when-to-use, when-not-to-use, or alternative is mentioned. With drift_certificate, trust_decay, trust_score, and agents_semantic_diff in the sibling list, the agent has no basis for choosing drift_check over any of them.

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