Skip to main content
Glama

Remover salva

remover_salva
DestructiveIdempotent

Remove a compra da lista pessoal do dono. Salvar não cria vigia nem notificação. O cliente fornece somente o ID; o retrato vem do acervo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesIdentificador da compra no acervo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried. The description adds real value beyond that: it clarifies the removal does not spawn a watch or notification and that the record's snapshot is sourced from the acervo, which are genuine side-effect disclosures.

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?

Three short sentences, front-loaded with the action and free of filler. The phrasing is slightly terse/cryptic in the second clause, but nothing is padded.

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?

For a single-parameter destructive tool with rich annotations and no output schema, most of what an agent needs is present. It does not state reversibility, whether a confirmation is required, or what the call returns, leaving modest gaps for a destructive operation.

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

Parameters3/5

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

Schema description coverage is 100%, so the 'id' parameter is already documented as the catalog identifier. The description's 'O cliente fornece somente o ID; o retrato vem do acervo' adds only marginal meaning about data sourcing and that no other field is needed — the baseline 3 applies when the schema does the heavy lifting.

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?

States a clear verb+resource: 'Remove a compra da lista pessoal do dono' — an agent knows this deletes a saved purchase from a personal list. It implies a boundary with the watch/notification siblings ('Salvar não cria vigia nem notificação') but never names vigiar_compra or salvas as the contrasting tools, so differentiation is implicit rather than explicit.

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?

Usage is only implied: the agent can infer this is for undoing a save. There is no explicit when-to-use vs when-to-use-alternatives guidance against siblings like salvar_compra, vigiar_compra, or salvas. The line 'O cliente fornece somente o ID' is an input note, not usage routing.

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