secondbrain

refine_entity_wiki

Destructive

Guarda en el WIKI del Atlas una conclusión sobre una entidad: algo SÓLIDO que el wiki no dice o dice mal (el rol o cargo de una persona, qué es un proyecto, con quién trabaja, un estado que sale de juntar varias fuentes).

El wiki lo escribe de noche un modelo chico con ~20 fragmentos; una conversación puede
cruzar muchas más fuentes. Lo guardado queda como aporte permanente: el wiki se
reescribe en el momento usándolo como fuente prioritaria, y cada reescritura futura lo
vuelve a leer. Es una escritura: para cuando la persona pide dejarlo asentado, o lo
acepta cuando se le ofrece.

tipo:
  definicion   qué es / qué rol tiene. "Pablo Ronco es el CTO de Veritran; …"
  conclusion   algo que sale de cruzar fuentes: estado, relación, patrón
  correccion   el wiki dice algo mal; decí qué es lo correcto

Qué SÍ: hechos que las fuentes sostienen, escritos para durar.
Qué NO: opiniones tuyas, recomendaciones, el pedido del usuario, cosas de "esta semana"
que envejecen en días, o lo que el wiki ya dice. Mirá get_entity_wiki (trae "aportes")
antes; si un aporte tuyo quedó viejo, reemplazalo con `reemplaza`.
Un aporte por entidad y por idea; texto autocontenido (nombrá a la entidad).

Input Schema

Name	Required	Description
`tipo`	Yes
`texto`	Yes	La conclusión, en español, autocontenida. 1–5 oraciones.
`basado_en`	No	Las fuentes del workspace en que se apoya
`entity_id`	Yes	ID de la entidad (de recall o search_entities)
`reemplaza`	No	ID de un aporte anterior que éste reemplaza
`workspace_id`	No	UUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir si el token ya tiene workspace fijo

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag this as a non-read, destructive write; the description goes further by disclosing the persistence mechanism — the wiki is regenerated nightly by a small model over ~20 fragments, the saved aporte becomes a priority source at rewrite time and is re-read on every future rewrite. That permanence and the one-aporte-per-entity-per-idea constraint are behavior the annotations cannot convey.

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?

Purpose and the core write semantics are front-loaded, and the SÍ/NO block is scannable. It is longer than strictly needed — the model/20-fragment backstory and the 'es una escritura' aside overlap — but nearly every line earns its place by disambiguating use.

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

Completeness5/5

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

With 6 parameters, no output schema, and destructive semantics, the description covers the write intent, the eligibility criteria for content, the tipo taxonomy, the prior-read prerequisite, and the replacement path. Nothing essential to invoking it correctly is missing.

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

Parameters4/5

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

Schema coverage is 83%, so the baseline is 3, but the description meaningfully enriches it: it defines each of the three `tipo` enum values with a concrete example and explains the intent of `reemplaza` ('si un aporte tuyo quedó viejo, reemplazalo'). It also constrains `texto` beyond the schema (autocontenido, nombrar la entidad, un aporte por idea).

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 and resource ('Guarda en el WIKI del Atlas una conclusión sobre una entidad') and immediately scopes what counts as a valid conclusion. It explicitly differentiates from the read-side sibling by pointing to get_entity_wiki ('trae aportes'), so the agent can tell write from read without opening either schema.

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 explicit when-to-use ('para cuando la persona pide dejarlo asentado, o lo acepta cuando se le ofrece') and when-not ('Qué NO: opiniones tuyas, recomendaciones, el pedido del usuario, cosas de esta semana... o lo que el wiki ya dice'). It names the prerequisite sibling call (get_entity_wiki) and the replacement path through `reemplaza`.

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

All secondbrain tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?