Item Save

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

With no annotations, the description carries the full behavioral burden and does so richly: batch is transactional (one error rolls back the lot and points at the offending entry), secret-like content is refused, secrets store no value and return a fill_url for the user to complete in the local UI, and similar-title detection fires on creation. This is exactly the operational context an agent needs before writing.

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

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

It is long, but the bold labels (Use quando / Retorna / Modo / Exemplo / Campos / Segredo / Notas) front-load the mode decision and the examples each demonstrate a distinct operation rather than restating one. Dense yet every block earns its place for a tool with this many modes; slightly heavy for quick scanning.

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

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

An output schema exists, yet the description still summarizes the return shape and, more importantly, covers the failure paths (rollback, refused secrets, rejected secret-like content) and the secret-filling workflow. Combined with the schema, an agent has everything needed to call this correctly on the first attempt.

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

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

Schema coverage is 0%, so the description must compensate — and it largely does, documenting the per-item mode switch (key → upsert in domain, id → update, neither → create + similar), the full field list (type, status, relations, scope_paths, memory_class/ttl_days, workspace/domain), and the project/domain fallback. Only connection_id is left unexplained.

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

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

The opening line states a specific verb and resource ("Grava itens") and enumerates the write modes it covers (criar, atualizar, upsert, renovar, relacionar) inside a transaction, so an agent immediately knows this is the write path. It never names the read/delete siblings (item_get, item_search, item_delete), but the semantics make the boundary obvious.

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

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

"Use quando" gives concrete triggering situations — persisting a user-stated rule, decisions/learnings from a completed change, a correction to an item. It gives no explicit when-not or named alternative (e.g. use item_search to look things up, item_delete to remove), so the negative space is left to inference.

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