Skip to main content
Glama

resumo_caso

Read or overwrite a persistent case summary file to preserve context across legal document sessions; previous versions are backed up automatically.

Instructions

Memória do caso que sobrevive entre conversas (resumo.md na pasta). Sem conteudo: lê. Com conteudo: sobrescreve (leia antes e preserve o que ainda vale; a versão anterior fica em resumo.md.bak). Atualize ao final de sessões relevantes.

Input Schema

NameRequiredDescriptionDefault
casoYes
conteudoNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/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 does well: it discloses the overwrite semantics, the resumo.md.bak backup of the prior version, and the advice to read before overwriting and preserve what still matters. It omits anything about permissions or concurrent-write risk, which is the only gap.

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 core concept (persistent memory) before the read/write mechanics and the usage nudge. Dense but every clause carries meaning; no filler.

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

Completeness4/5

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

An output schema exists, so return values need not be described. For a file-backed read/overwrite tool with no annotations, the description covers the destructive behavior and backup path adequately; only the meaning of the required 'caso' argument remains thin.

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 coverage is 0%, so the description must compensate. It explains conteudo's dual semantics thoroughly (absent = read, present = overwrite), but the required 'caso' parameter is never defined beyond the implied 'na pasta' phrasing. Partial compensation for a 2-param tool.

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 specific verb+resource: a persistent case memory stored as resumo.md in the case folder, with read-vs-overwrite behavior keyed on whether conteudo is supplied. It is clearly distinct from siblings like status_caso or listar_casos, though it never names an alternative explicitly.

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?

Gives concrete usage context: 'Atualize ao final de sessões relevantes' tells the agent when to call it, and the read/write branching tells it which mode applies. It stops short of naming sibling tools as alternatives, so it is clear context without explicit exclusions.

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