Skip to main content
Glama

Error-actionability translation for MCP tool failures

error_enforce

Gateway enforcement: if a prior non-retryable verdict exists for this (server, tool, identical args), the resend is refused without forwarding; otherwise classify + record the verdict

Input Schema

NameRequiredDescriptionDefault
argsYes
toolYes
proseYes
serverYes
mutatingYes
structuredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses important behavior: resends may be refused without forwarding, and otherwise the tool classifies and records a verdict (a write side effect). It does not explain what a 'non-retryable verdict' is, what the refusal returns, or error conditions, which keeps it from a 5.

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 compact sentence that front-loads the tool's role and then states the conditional behavior. It is dense but efficient, with no filler.

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?

No annotations and no output schema mean the description must carry all behavioral context. It explains the central refusal/classification mechanism but omits parameter meanings, return/error behavior, and the definition of a non-retryable verdict, leaving meaningful gaps for a tool with five required parameters and nested objects.

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 six parameters exist. The description implies meaning for 'server', 'tool', and 'args' via '(server, tool, identical args)', but says nothing about 'mutating', 'prose', or 'structured'. The majority of parameters remain undocumented anywhere.

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?

The description gives a specific verb+resource ('Gateway enforcement') and explains the core mechanism (refuse resend if a prior non-retryable verdict exists, otherwise classify and record). It is distinguishable from error_classify by its enforcement/refusal behavior, though it does not name that sibling explicitly.

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?

The conditional logic ('if a prior non-retryable verdict exists... otherwise classify + record') implies when the tool will refuse versus classify, but it never states when an agent should choose this tool over alternatives like error_classify or verdict_stats. Usage is inferable but not explicit.

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