Skip to main content
Glama
retrace-mcp

retrace-mcp

by anthoo582

retrace_limits

Displays active safety limits and classifies an operation before destructive actions so users can confirm risk levels first.

Instructions

Show the active safety limits and the level classification of an operation before doing anything destructive.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden; 'show' implies a read-only, non-mutating call, and 'before doing anything destructive' hints at a safety-gating role. It does not say whether limits are static configuration or state-dependent, whether the result blocks a subsequent action, or what a 'level classification' signifies, leaving the agent unable to act on the answer confidently.

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?

A single front-loaded sentence with the call trigger placed at the end where it is easy to scan, and no filler. The trailing clause 'of an operation' is slightly confusing given the empty schema.

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?

There is no output schema, no annotations and no parameters, so the description is the only source of information about the response — yet it never explains the shape of 'limits' or what the classification levels are. For a pre-flight safety gate whose output determines whether the agent proceeds, that is a meaningful gap.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4 and no compensating description text is needed. The phrase 'of an operation' is the only weak point, since no parameter exists to supply that operation.

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 'show' and resource 'active safety limits and the level classification' give a rough sense of a read-only gate tool, but 'of an operation' is ambiguous because the tool takes no parameters — it is unclear whether the caller must first name an operation elsewhere or whether the response is global. It is distinguishable from siblings like retrace_probe only by inference, not by an explicit contrast.

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

Usage Guidelines4/5

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

'before doing anything destructive' gives a concrete call trigger, which is more than most siblings offer. It stops short of naming which sibling tools count as destructive or stating whether the call is mandatory, so the agent must infer the set of operations it gates.

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