Skip to main content
Glama

registrar_aprendizado

Records non-obvious learnings and insights, such as tool pitfalls, technical reasons, or measured results, into project memory so they persist across conversations.

Instructions

Registra um aprendizado/insight não óbvio em Aprendizados/ (pegadinha de ferramenta, motivo técnico, resultado medido). Use proativamente quando algo assim surgir.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
forcarNo
tituloYes
projetoNo
conteudoYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write/safety profile is covered structurally. The description adds the storage location (Aprendizados/) and the non-obviousness filter, but stays silent on the semantics of the "forcar" flag (force/overwrite? bypass dedup?) and on what happens with duplicate entries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the action and destination, and the parenthetical examples earn their space by narrowing what counts as an eligible insight. No filler.

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

Completeness2/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 needn't be explained, but for a five-parameter mutation tool with zero schema descriptions and no annotation-level detail on the force flag, the description is too thin. The agent lacks enough information to decide when to set "forcar" or how "projeto" scopes the write.

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%, so the description carries the full burden, yet it explains none of the five parameters. Notably "forcar" (force) and "projeto" (project) are non-obvious from their names alone and are nowhere clarified, nor are titulo/conteudo/tags formats described.

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 and target ("Registra um aprendizado/insight não óbvio em Aprendizados/") and even enumerates the content categories it accepts. An agent can tell what it writes and where, but the definition never differentiates itself from the closely related sibling registrar_decisao or criar_nota.

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?

"Use proativamente quando algo assim surgir" gives a genuine trigger condition (non-obvious insight), which is more than nothing. However it offers no exclusion criteria and never names alternatives such as registrar_decisao, leaving the agent to infer the boundary between the two registration tools.

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