Skip to main content
Glama

atualizar_nota

Append new details, results, or corrections to an existing note in a dated Updates section without deleting prior content; use for updates to already recorded notes.

Instructions

Atualiza uma nota/decisão/aprendizado EXISTENTE em vez de criar outra: acrescenta, numa seção datada "Atualizações", só as frases que a nota ainda não tem (número, arquivo ou sentido novo). Nunca apaga. Use quando surgir detalhe, resultado ou correção sobre algo já registrado. Se a decisão MUDOU (contradiz a anterior), use registrar_decisao com substitui.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notaYes
textoYes
so_novidadesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=false, and the description reinforces this with 'Nunca apaga' and explains the mechanism (appends only new sentences in a dated 'Atualizações' section). That is meaningful behavioral disclosure beyond the annotations; it stops short of covering permissions or edge cases.

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?

Front-loaded with the verb and the core constraint, and every sentence (append behavior, non-destruction, trigger, alternative) earns its place. Slightly dense but 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 mutation tool the description covers what changes, what is preserved, and when to prefer an alternative, leaving only parameter-level detail unaddressed.

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 carry the parameter burden. It conveys the dedup semantics ('só as frases que a nota ainda não tem'), which maps onto the so_novidades boolean default, but never explains the 'nota' target or 'texto' payload, nor what so_novidades=false does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (atualiza) and resource (nota) plus the key differentiator: it updates an EXISTING note rather than creating a new one. It also names the sibling it contrasts with ('use registrar_decisao') so the agent can route correctly without opening schemas.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use trigger ('Use quando surgir detalhe, resultado ou correção sobre algo já registrado') and an explicit when-not with an alternative ('Se a decisão MUDOU, use registrar_decisao com substitui'). Both dimensions of guidance are present.

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