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

With no annotations, the description carries the full burden and discharges much of it: it discloses the 504/timeout behavior right after page creation, the `onde` placement semantics (fim/inicio/#id), how attachments are cited (anexo:N), and that titles must travel in the parameter rather than the body. It does not cover permissions or what the call returns, but for a no-annotation tool this is unusually informative.

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?

The purpose sentence is buried behind a generic workflow preamble (read the spec, read the page, imitate neighbors, report warnings) that reads more like server-level instructions than tool-specific content. Every line does convey something useful, but front-loading the actual 'what this does' would improve scannability.

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?

No output schema and no annotations exist, so the description must stand alone, and it covers placement, attachments, error timing, and authoring style. Missing pieces are the return value (does it return new block ids?) and the expected `pagina_id` identifier format.

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 largely does: it enumerates the `onde` values and default, explains the `anexos` collection and its anexo:N citation convention, and states where the title belongs. `pagina_id` and `conteudo` are left only implicitly defined, which is the remaining gap.

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 sentence 'Acrescenta ONMD numa página que já existe' states a specific verb (append/insert content) and resource (an existing OneNote page), and the `onde` parameter clarifies the placement model. It never names the siblings it overlaps with (inserir, editar, criar_pagina), so an agent must infer the boundary with those tools, which keeps it below 5.

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?

Strong procedural guidance: read ler_spec before writing, read ler_pagina before editing, make the smallest possible edit, re-read after structural changes, and wait a few seconds after page creation due to 504s. What is missing is an explicit when-not/alternative clause naming inserir or editar, which is the one thing that would push this to 5.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: substring matching, case-insensitivity, title-only scope, and the OneNote limitation that page text cannot be searched. It does not disclose pagination or ordering behavior of results.

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?

Three short sentences, front-loaded with the core behavior and then the constraints. Every sentence adds information; no filler or restatement of the tool name.

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?

For a read-only search tool with no annotations and no output schema, the essential scoping rules are covered, but return shape and result limiting are left unstated. Adequate rather than complete.

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. It implicitly documents `texto` (the search term) and explains the purpose of `bloco` with a concrete trigger condition, but `limite` (default 20) is never mentioned despite being the result-capping control.

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?

States a specific verb and resource ('Procura páginas') and narrows the match to the TITLE with contains/case-insensitive semantics, which cleanly separates it from listar_paginas. It never names the sibling it is not, so the differentiation is inferred rather than explicit.

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?

Gives concrete operating context: only allowed sections are searched, and when more than 20 sections exist the caller should restrict with `bloco`. That is a real when-to-use condition. It does not contrast with listar_paginas or ler_pagina for the case where the caller already knows the section.

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

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

With no annotations at all, the description carries the full behavioral burden and does reasonably well: it discloses the return payload ('Devolve id, link e avisos'), the ONMD content format, the rule that the title must go in the parameter and never in the body, and how retroactive dates work. It omits permission/auth requirements, duplicate-title behavior, and failure modes, so it is not fully complete.

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?

The purpose statement is not front-loaded; the reader must wade through workflow text first. Worse, several sentences are about editing rather than creating ('Antes de editar, leia a página...', 'Depois de edição estrutural, releia'), which belongs to the editar tool and dilutes this definition. The remaining content is dense and earns its place.

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?

For a 5-parameter tool with a nested anexos object, no annotations, and no output schema, the description covers the essentials: what it creates, the content format, attachment mechanics, date handling, and what is returned. Missing are authorization expectations and error/duplicate behavior, but an agent could call it correctly with what is here.

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 description coverage is 0% for the top-level parameters, so the description must compensate and largely does: secao accepts an id or path, conteudo is ONMD, anexos is documented with an inline JSON example plus the citation syntax  / <anexo n=2/>, criado_em is AAAA-MM-DD, and titulo's placement is stated. Only minor format details (e.g. exact section path syntax) are left implicit.

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 description contains a clear verb+resource statement: 'Cria página nova na seção (id ou caminho)', and it is obvious this is a creation tool rather than a mutation of existing content. However, the purpose sentence is buried after a paragraph of workflow instructions, and it never explicitly contrasts itself with close siblings like editar, inserir, or acrescentar, leaving the agent to infer the boundary.

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?

The opening paragraph gives process context ('Antes de escrever, leia a spec... não invente sintaxe', 'Faça a menor edição possível', 'Relate os avisos'), which is genuinely useful pre-write guidance. But it does not answer the key routing question for this tool family: when to create a new page versus edit/insert into an existing one via editar or inserir. Usage is implied rather than explicitly scoped.

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

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

With no annotations, the description carries the full burden and delivers: validation is atomic (if one swap fails, nothing is sent), `novo` may not empty an entire block, table cells rewrite the whole table, existing images/attachments cannot be edited, and prior state is kept in a local log. These are exactly the destructive/side-effect traits an agent needs.

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?

Front-loads prerequisites, then mechanism and constraints, then an example — a sensible order. Dense but nearly every sentence carries a rule or a warning; a little tightening is possible.

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?

Covers workflow, atomicity, per-field constraints and failure behavior for a mutation tool with no annotations and no output schema. Return/warning format is only gestured at ('Relate os avisos'), so one gap remains.

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?

Adds real meaning beyond a 0%-coverage schema: `antigo` must appear in exactly one block unless `todas=true`, `novo` cannot blank a block, and swap semantics are illustrated with a concrete example. Some overlap with the nested Troca property descriptions keeps this from a 5.

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 generic name 'editar' is rescued by 'Troca trechos', which pins the tool to excerpt-swap editing on a page rather than free-form writing. It implies a distinct mechanism from siblings like inserir/acrescentar but never names them, so differentiation is inferred rather than explicit.

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?

Gives explicit preconditions (read the spec via ler_spec first, read the page via ler_pagina before editing, re-read after structural edits) and directs the agent to imitate existing titles/colors/patterns and make the smallest possible edit. This is genuine do-this-before-that workflow guidance.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals that 'ancora' must match a snippet in exactly one block (implying ambiguity handling), that warnings are surfaced, and that titles belong in a parameter rather than the body. It says nothing about permissions, failure behavior when the anchor is not found, or side effects of the mutation.

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?

The size is moderate and most sentences carry real instruction, but structure is poor: the core purpose sentence is buried in the second paragraph behind a run of process reminders, and parameter notes are interleaved with workflow advice. Front-loading the what/where would improve it substantially.

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?

For a five-parameter mutation tool with no annotations and no output schema, the description is reasonably rich on workflow but incomplete on specifics: attachment semantics, page identifier meaning, and the shape of the response/warnings are all left implicit. It is usable but not self-sufficient.

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?

Top-level schema description coverage is 0%, so the description must compensate. It defines 'ancora' (unique snippet or #id) and 'posicao' (antes/depois) clearly and gives content-writing guidance for 'conteudo,' but leaves 'pagina_id' and the 'anexos' array wholly undocumented in the description.

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 second paragraph states a specific verb and scope: "Insere ONMD antes ou depois de um bloco," which tells an agent it inserts content at a block anchor rather than appending to a page. The distinction from siblings like 'acrescentar' or 'editar' is implied by the before/after-block scoping but never named explicitly, and the term ONMD is left unexplained.

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?

It gives concrete prerequisites and process conditions: read the spec via ler_spec before writing, read the page via ler_pagina "se ainda não leu," make the smallest edit, and re-read after structural edits. These are actionable usage cues, though it never states when to prefer this tool over 'acrescentar' or 'editar,' so exclusions are absent.

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

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

With no annotations, the description carries the full burden. It usefully discloses output behavior (images/attachments rendered as recurso:<id>, marks must be preserved, incluir_ids exposes block ids), but says nothing about permissions, size limits, or error cases for a read operation.

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?

Short, dense and front-loaded: the format statement comes first, then the attachment caveat, then the parameter note. No filler sentences, though the phrasing is slightly terse.

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?

No output schema and no annotations, yet the description only partially covers the return shape. It explains the ONMD body and the recurso:<id> convention but leaves pagina_id semantics and any pagination/error behavior unaddressed.

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 schema documents neither parameter. The description explains incluir_ids (shows {id=…} of blocks), but pagina_id is only implied via the tool name, leaving half the parameters without explicit meaning.

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 description states the resource and its representation ('Página em ONMD'), which combined with the name ler_pagina makes it clear this reads a single page's content. It implicitly distinguishes itself from listar_paginas/buscar_paginas by describing the page body format, but never says the explicit verb 'read/lê'.

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?

No when-to-use guidance and no routing to alternatives. It notes the format matches writing tools, but does not say when to use ler_pagina vs buscar_paginas, listar_blocos, or ler_spec.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the important coupling – the returned format is exactly what write tools expect and what `ler_pagina` emits – which is genuine context beyond the schema. However, it says nothing about whether the content is static, cacheable, or versioned, and the read-only nature is only implied by the name.

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?

Two short sentences, with the resource statement leading and the imperative usage cue following. The parenthetical acronym expansion adds necessary meaning rather than padding. Tight and front-loaded, with no wasted clauses.

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, so return values need no explanation in the description, and the parameter-less schema is fully covered. The description supplies the one thing an agent needs beyond structure: the read-before-first-write sequencing relative to the sibling write tools. Adequate for a simple documentation-fetch tool.

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?

The tool takes zero parameters, so per the baseline there is nothing for the description to compensate for. The schema is trivially complete and no parameter explanation is needed.

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 description identifies the resource concretely – the ONMD (OneNote markdown) format spec – and ties it to `ler_pagina` (which returns it) and the write tools (which accept it). Combined with the name `ler_spec`, the agent understands this returns a format documentation document, distinct from the page-operating siblings. The framing is slightly indirect (it describes the content rather than saying 'returns the spec'), keeping it below a 5.

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?

'Leia antes da primeira escrita' gives explicit lifecycle guidance: read this before performing any write. It implicitly identifies the write-tool siblings as the context where this prerequisite applies. It doesn't state when *not* to use it or how often it must be re-read, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the burden. It does disclose one meaningful behavioral trait: results are restricted to a permission/allow list rather than all notebooks the account can see. It says nothing about ordering, pagination, auth requirements, or whether unreachable notebooks are silently omitted.

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?

A single compact sentence with no padding, and the resource plus scope are front-loaded. It is slightly under-specified rather than over-long, but nothing is wasted.

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?

For a zero-parameter list tool with no annotations and no output schema, the description covers what is returned and the allow-list restriction, which is the essential minimum. It still lacks the when-to-use routing against three closely related list/search siblings that an agent would need to select correctly.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description partly compensates by naming the returned fields (name, shared status, account role), which is useful in the absence of an output schema.

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 description names a specific resource (OneNote notebooks/blocos de anotações) and a scope qualifier (those in the allowed list). It is distinguishable from siblings like listar_secoes and listar_paginas by resource type, though the listing verb itself is only implied by the tool name rather than stated in the text.

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?

There is no guidance on when to use this tool versus listar_secoes, listar_paginas, or buscar_paginas. The 'allowed list' phrase hints at a filtering context but never states a triggering condition or exclusion.

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

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

No annotations exist, so the description bears the full behavioral burden. It usefully discloses the sort order ('da alteração mais recente para a mais antiga') and what com_nivel returns (recursion level, subpage = 1, 2), but is silent on result limits, pagination, permissions, or what fields each page carries.

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?

Two tightly-packed sentences: the resource and ordering come first, then the optional parameter's effect. No filler or repetition of the name.

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?

For a two-parameter listing tool with no output schema and no annotations, the description covers input semantics and ordering but omits return shape, volume/pagination behavior, and error conditions, leaving meaningful gaps an agent would want filled.

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. It explains the accepted format for 'secao' (id or 'Bloco/Grupo/Seção' path) and the exact effect and value semantics of 'com_nivel', which the bare boolean schema does not.

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?

States a specific verb+resource ('Páginas de uma seção') and adds scope details (id or path format, sort order). An agent can tell it lists pages rather than blocks or sections. It does not, however, explicitly contrast itself with the sibling buscar_paginas, so it stops short of a 5.

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?

The description never says when to choose this tool over buscar_paginas, listar_blocos or listar_secoes, nor does it state prerequisites (e.g. that the section must exist). Usage is only implied by the tool's name and structure.

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

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

With no annotations, the description carries full behavioral burden. It hints at a permission scope ("permitidas") and discloses the return shape (id + path), but says nothing about access requirements, ordering, completeness of results, or whether the listing is paginated or cached.

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?

Two short sentences with no filler, and the return shape is front-loaded before the parameter note. Grammatically terse but every clause carries information.

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?

For a single-optional-parameter read tool with no output schema and no annotations, the description covers the return fields and the filter semantics, which is close to adequate. It still lacks any routing guidance among the many sibling listing tools, leaving a real gap.

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% and the single `bloco` parameter has no schema description, so the burden falls on the prose. The description does compensate meaningfully by stating the filter is a prefix match on the path ("filtra pelo começo do caminho"), but it omits format, expected casing, and whether an empty value returns everything.

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?

States the resource (permitted sections) and what it returns (id and the "Bloco/Grupo/Section" path), which is a clear verb+resource pairing even though the listing verb is only implied. It does not, however, distinguish itself from siblings like listar_blocos or listar_paginas, which also enumerate hierarchy items.

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?

The description only explains what the optional `bloco` parameter does; it never says when to call this tool instead of the closely related listar_blocos/listar_paginas/buscar_paginas. An agent must infer the choice from the tool name alone.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the operation mutates state (marks/unmarks, reversible via feito) and hints that warnings may be returned ('Relate os avisos'), but says nothing about permissions, failure modes, or what a successful response contains.

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?

The prose is not wasteful in raw length, but it opens with a block of generic workflow rules that apply broadly across write tools, and only reaches the actual purpose ('Marca ou desmarca uma caixa de tarefa') at the end. Reordering so the operation leads would improve structure.

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?

With no annotations, no output schema, and 0% parameter coverage, the description provides meaningful workflow guidance but omits error behavior, permission requirements, and return format. Adequate as a minimum-viable definition, with clear gaps for a mutation tool.

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. It explains `tarefa` (an excerpt appearing in only one task, or a #id) and implicitly `feito` (feito=true marks), but leaves `pagina_id` completely unexplained in either schema or description. Two of three parameters are partly clarified.

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 description states a specific verb+resource: 'Marca (feito=true) ou desmarca uma caixa de tarefa' — marking or unmarking a task checkbox. This is clearly distinguishable from siblings like editar or acrescentar. However the purpose statement is buried at the very end after a block of generic workflow boilerplate, which weakens its front-loading.

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?

It gives substantial procedural guidance (read spec before writing, read page before editing if not already read, imitate neighboring patterns, make the smallest possible edit, reread after structural edits, report warnings). These are useful prerequisites, but they are generic write-tool rules rather than guidance on when to choose this tool over editar or another sibling, and the when/when-not distinction is only implied.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: empty titles are refused (input validation) and the previous title is retained in the local log (side effect/reversibility). It omits permissions, whether concurrent renames conflict, and any response/confirmation behavior.

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?

The actual purpose sentence is buried in the second paragraph behind a long generic workflow preamble that reads as shared boilerplate across sibling tools. The most important clause for tool selection is the last one the agent reads, so the definition is poorly front-loaded.

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?

Given zero annotations, no output schema, and 0% parameter coverage, the description does supply purpose, validation, a side-effect note, and read-before-write prerequisites. It still leaves the identifier parameter and the post-rename result undescribed, so it is only adequate, not complete.

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 description coverage is 0% and neither parameter is documented in the schema. The description only constrains 'titulo' (must be non-empty, goes in the parameter not the body); 'pagina_id' receives no explanation of format, source, or lookup semantics, leaving half the parameters undocumented everywhere.

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 second paragraph states a specific verb and resource: 'Muda o título da página' (changes the page title), which is unambiguous. However, it does not differentiate itself from the sibling 'editar', which plausibly also mutates a page, so the agent must infer that this tool is the title-only path.

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?

The preamble gives conditional workflow steps ('read the page before editing if you haven't read it', 'read the spec before writing'), which implies usage context. It never states when to pick this tool over 'editar' or 'criar_pagina', so routing remains inferred rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It adds one valuable behavioral trait – that text inside the image is data, not instruction (a prompt-injection guard) – but omits the return format (image bytes, URL, rendered?), size or rate constraints, and does not explicitly confirm it is read-only.

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?

Two short, front-loaded sentences with no filler: the purpose comes first, then the id source and the safety caveat. Efficient, though the parenthetical could be tightened.

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?

For a read tool with no annotations and no output schema, the description should at least indicate what is returned, which it does only implicitly via 'Mostra uma imagem'. The injection-safety note is a good addition, but return format and error conditions remain unstated.

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 description coverage is 0% and there are two required params. The description explains the provenance of recurso_id ('lido em ler_pagina') but says nothing about pagina_id. It partially compensates for the coverage gap but leaves one parameter undocumented.

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?

States a specific verb and resource ('Mostra uma imagem da página'), distinguishing it from text-reading siblings like ler_pagina. It also clarifies the dependency chain by pointing to where the resource id originates. Clear, though it doesn't explicitly contrast itself against other listar_/ler_ siblings.

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?

Implies the workflow by noting the resource id is 'lido em ler_pagina', so an agent understands ler_pagina must run first. However, it gives no explicit when-to-use/when-not guidance or exclusions relative to the other viewer/reader tools.

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