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

No annotations exist, so the description carries the burden; it does usefully signal that the tool is advisory ('sugere reformulações') rather than rewriting the text, and lists what it flags. However it does not state whether it works only on Portuguese text, whether there are length limits, or how findings are reported, which matters for a zero-annotation tool.

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 front-loaded sentence followed by four tight bullets, each of which adds distinct, non-redundant information. Nothing repeats the name or title.

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-value explanation is not needed, and the detection list covers the core behavior well. The main remaining gap is language/scope constraints and the absence of any routing guidance among the many sibling tools.

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?

There is one parameter ('text') at 0% schema description coverage; the description implies it should be academic prose but never says so explicitly or mentions language, format, or size expectations. The bullet list explains what is analyzed more than what to pass in.

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 object ('analisa o rigor científico e a impessoalidade da escrita acadêmica') and enumerates the exact phenomena detected (first person, unsupported value judgments, colloquialisms, uncited paragraphs). This clearly separates it from siblings like validate_citations or check_structure, which address different concerns.

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?

Usage is implied by the domain (academic writing review) but there is no explicit statement of when to call this versus check_structure, validate_citations, or audit_research_spec, nor any exclusion criteria. An agent must infer the placement in the workflow.

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; the verbs (Detecta, Aponta, Verifica, Diagnostica) clearly signal a read-only inspection, and it discloses that it touches the physical filesystem to verify image existence. It does not state whether any files are modified, permission requirements, or how results are ranked, though an output schema exists to cover structure.

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-loaded purpose sentence followed by four tight bullets, each earning its place with a concrete rule ID. The only friction is the Portuguese body against an English tool name, a minor consistency cost.

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 one-parameter diagnostic with an output schema handling return shape, the definition covers what is audited and by which rule. Remaining gap is mostly path expectations for the single input.

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% on a single parameter, so the schema supplies no meaning; the description only implies project_path is the project root whose referenced images are checked. It does not define expected form (relative vs absolute, must the project follow a scaffolded layout).

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 (audit) and precise resources (figures, tables, quadros) plus the governing standards (NBR 14724 item 5.8, IBGE 1993). It does not explicitly contrast with siblings format_figure/format_table, but the enumerated checks make the auditing scope unmistakable.

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?

Usage is implied by the diagnostic checklist (missing textual callouts, missing 'Fonte:', broken image paths, out-of-sequence numbering) rather than stated as when-to-run. No exclusion tells the agent to prefer format_table or format_figure for fixing rather than auditing issues.

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 usefully discloses the output content (violations tagged with canonical rule IDs), which is behavior beyond the schema, but says nothing about whether the audit is read-only, what happens if spec_path is absent, or whether a report file is written.

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-loaded with the core action, then three tight bullets enumerating exactly the checks. Little waste; the rule-ID list in the third bullet is dense but justified as it tells the agent what identifiers to expect.

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?

Having an output schema means return values need not be explained, and the description covers the check semantics well. However, with both parameters undocumented and no annotations, the definition leaves the agent without enough to know what paths to supply or what side effects to expect.

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 two parameters. The description names the 'abnt.spec.json' manifest, which hints at spec_path, but never explains what project_path points to (directory vs. manuscript file) nor what the null default for spec_path means behaviorally. An agent must guess the parameter contract.

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: audits an academic manuscript against the 'abnt.spec.json' manifest, and enumerates the three concrete checks performed (objectives discussed/answered, planned chapters and minimum .bib references, canonical rule-ID violations). This clearly differentiates it from narrower siblings like check_structure and validate_citations, though it does not explicitly name those 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?

The bullets imply when the tool applies (a full spec-driven compliance audit of a manuscript), but there is no explicit statement of when to use this versus check_structure, validate_citations, or audit_illustrations_and_tables, all of which overlap with its checks. With 17 siblings and heavy functional overlap, the missing routing guidance is a real gap.

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 must carry the behavioral burden, and it does partially: it discloses a non-obvious negative behavior (optional lists are not penalized) and the diagnostic scope. It does not state whether the operation is read-only or mutates the project, nor what happens on a missing/invalid path, which leaves the safety profile undefined for an agent.

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-loaded with the core purpose and then broken into scannable bullets, each of which adds a distinct scope item. Slightly redundant phrasing ('Verifica elementos...' repeated) but no filler.

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 not be explained, and the check scope is well covered. The gap is on the input side: with 0% schema coverage and no annotations, the agent is left guessing what 'project_path' should point at and that 'standard' is a selectable parameter.

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 parameters, yet the description never mentions 'project_path' or 'standard'. Since 'standard' defaults to ABNT_14724 and the whole description is written as ABNT-specific, the agent gets no signal that other standards might be selectable or what path format is expected.

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 ('Valida a conformidade da estrutura acadêmica') pinned to a named standard (ABNT NBR 14724:2011), then enumerates exactly which elements are checked (pré-textuais, textuais, pós-textuais) and which NBR 6024 numbering errors are diagnosed. This is clearly distinguishable from siblings like audit_illustrations_and_tables or validate_citations, which cover different surface areas.

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 bullet outlining that optional lists (figuras, tabelas, siglas) are not penalized implicitly tells the agent what this tool does and does not flag, which is useful usage context. However, no explicit when-to-use signal, no named alternatives, and no prerequisites (e.g., whether the project must be scaffolded first) are given.

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 does disclose real behaviors: encoding conversion, month normalization including the 'maio' edge case, and that validation runs 'sem corromper ou perder chaves'. It does not say whether the target file is modified in place or a new file is written, what happens when required fields are missing (abort vs. report), or whether the operation is idempotent.

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-loaded one-line purpose followed by three tight bullets, each earning its place with a concrete rule (including the useful 'maio without period' detail). Minimal waste; only the standard-number citation borders on boilerplate.

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?

Return values are covered by the output schema and the transformation contract is fairly well specified, but for a file-mutating tool with zero annotations and 0% schema coverage, the write semantics (in-place vs. output_path, overwrite behavior, error handling on validation failure) are missing and would matter to an agent deciding how to call it.

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 the description never mentions either parameter. The critical ambiguity — whether bib_path is cleaned in place or output_path must be supplied — is left entirely unexplained, so the description does nothing to compensate for the undocumented 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?

States a specific verb + resource ('Higieniza e normaliza um arquivo BibTeX') and pins it to a named standard (ABNT NBR 6023:2018), then enumerates three concrete operations. This clearly separates it from single-item tools like format_citation/format_reference and from validate_citations, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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 statement of when to call this versus validate_citations or check_structure, no prerequisite (e.g. run before compile_tcc), and no exclusion. The only usage signal is implicit in the enumerated transformations, which an agent must interpret as 'call this when the .bib has encoding/month/field problems'.

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 does useful work: it discloses the multi-pass LaTeX cycle to avoid unresolved '[?]' references, a syntax pre-check stage, and friendly diagnostics — real behavioral traits beyond the schema. However, it omits that this is a write-side operation producing a PDF on disk, where the artifact lands, and whether a syntax failure aborts compilation or returns partial diagnostics.

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 dense sentences with the resource and engine list front-loaded, and no filler phrasing. Slightly overloaded with parenthetical detail, 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?

The output schema covers return values, so that need not be described. Still, for a build tool with zero annotations and 0% parameter coverage, the definition should state output artifact location and the semantics of 'auto' and project_path to be complete enough for confident invocation.

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%, so the description carries the full burden. It does map Pandoc to markdown and confirm the LaTeX/Typst engine choices, but never explains what 'auto' does or what project_path should point at (project directory vs. main .tex file), which is the required parameter.

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 (compile the academic project to PDF) and enumerates the concrete toolchain options: LaTeX/abnTeX2, Typst, and Pandoc --citeproc. It is distinguishable from validation siblings like check_structure, though the 'pre-check of syntax errors' clause blurs that line slightly and no sibling is named explicitly.

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 invoke this versus check_structure, validate_citations, or audit_illustrations_and_tables, and no prerequisite conditions are stated. It also does not say when to leave engine at 'auto' versus forcing latex/typst/markdown, leaving the caller to infer the workflow.

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 behavioral burden. It helpfully discloses the content-negotiation retrieval path, the optional append side effect, and deduplication of keys/DOIs, but it omits authentication, rate limits, failure behavior, and whether existing files are created or only appended to.

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 description is a single front-loaded sentence with no wasted material. It is dense but appropriately sized, though splitting retrieval from optional write behavior would improve scanability.

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 do not need explanation. Still, for a tool with an optional write side effect and no annotations, the description should clarify file-path behavior and error cases to be fully 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?

Schema description coverage is 0%, so the description must add parameter meaning. It explains that 'doi' is a DOI and that 'bib_file' is an optional project .bib target for appending, but it does not specify path format, what null means beyond being optional, or how duplicates are detected.

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 and resource: retrieve the official BibTeX entry for a DOI. It also mentions the content-negotiation mechanism and optional append behavior, making the operation clear, though it does not explicitly distinguish itself from sibling tools such as clean_bibtex_file or format_citation.

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?

Usage is implied by 'corresponding to a DOI' and 'optionally appends to the project .bib file.' However, it gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives.

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 behavioral burden, and it does disclose the concrete transformation rules (surname casing, quote wrapping, indentation/font for long quotes). However, it says nothing about side effects, determinism, or that it is a pure formatter, so the transparency is partial rather than 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 standard is front-loaded and the three bullets each carry a distinct rule with concrete examples. It is efficient, though the examples are somewhat verbose relative to the information gained.

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 not be described, and the formatting rules are well covered. But for a 7-parameter tool with no annotations and 0% schema coverage, key parameters like page and target_format remain unexplained, leaving the definition incomplete.

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% across 7 parameters, so the description must compensate. It implicitly illuminates quote_type (short/long/indirect) and style (parentheses vs in-text) through its rules, but says nothing about page, authors, quote_text, or target_format, leaving most parameters 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?

The description opens with a specific verb and resource ('Formata chamadas de citação') bound to a named standard (NBR 10520:2023), which lets an agent distinguish it from format_reference. It does not explicitly name the sibling it excludes, 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 text describes formatting rules but never states when to invoke this tool versus format_reference or validate_citations, both plausible siblings. There are no prerequisites or exclusion conditions, leaving routing to inference.

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 carries the burden. It does disclose useful behavior – the dynamic default source using the current year and that the output is ready-made snippets in Markdown/LaTeX/Typst – but it never says whether an actual file is written or text is merely returned, whether image_path must exist on disk, or whether the image is validated/embedded.

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-loaded with the standard and purpose, then four tight bullets covering each output element with no filler. A couple of bullets are compressed to the point of ambiguity (what exactly 'Imagem centralizada com caminho no computador' means for the rendered caption).

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 an output schema available, the description needn't describe return values, and it does cover the main behaviors and the three target formats. The remaining gap is operational: nothing says whether the tool mutates a project file or only returns snippet text, which matters for a 5-parameter formatting 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 description coverage is 0%, so the description has to compensate, and it loosely maps all five parameters: caption ('Título'), figure_number ('Figura X'), image_path ('caminho no computador'), target_format (Markdown/LaTeX/Typst) and source ('fonte obrigatória', dynamic default). It still leaves gaps – e.g. that figure_number accepts an integer or a free string, and whether source overrides the dynamic year.

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 ('Formata uma figura/imagem') plus the governing standard (ABNT NBR 14724), and enumerates the concrete artifacts produced (top identification, centered image, mandatory source footer). This clearly separates it from the sibling format_table and the citation-formatting tools without needing the schema.

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?

Usage is only implied by the ABNT context and the mention of a 'chamada obrigatória no texto' – the agent can infer it is for figures in an academic document, but there is no explicit when-to-use/when-not or pointer to an alternative (e.g. format_table for tables, audit_illustrations_and_tables for checking compliance).

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 must disclose behavioral traits. It describes formatting rules (alignment, emphasis placement, month abbreviation) but says nothing about whether the tool is pure (no side effects), what it returns, or any error conditions. The formatting specifics add some value, but the overall behavioral profile remains under-specified.

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 description is appropriately sized and front-loaded with the core purpose. The bullet points are compact and each adds a concrete formatting rule. There is no redundant filler, though the bullets could be interpreted as output details rather than input guidance.

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 tool with 15 parameters, no annotations, and 0% schema coverage, the description is incomplete. It does not explain how to supply the inputs, does not clarify the required vs optional parameters, and does not cover the expected behavior beyond formatting rules. The output schema exists, so return values are partly covered, but the input side is neglected.

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 there are 15 parameters, yet the description provides minimal mapping. It hints at title versus subtitle handling and emphasis style, but does not explain the roles of parameters like entry_type, authors, year, or most others. An agent would have to infer parameter usage from the schema alone, which lacks descriptions.

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 first sentence states a specific verb and resource: 'Formats a bibliographic reference according to ABNT NBR 6023:2018.' The following bullets detail formatting rules, which reinforce that this tool applies ABNT styling to reference entries. However, it does not explicitly distinguish this tool from the sibling 'format_citation', leaving ambiguity about when to choose one over the other.

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 provides no guidance on when to use this tool versus alternatives. It never mentions sibling tools like format_citation or explains scenarios where one is preferred. There are no prerequisites or conditions for use.

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 must carry the behavioral burden, and it does disclose something important: it produces snippets in three markup formats rather than mutating files, implying a pure computation. It does not state whether anything is written to disk, whether an existing table number is validated, or how ABNT source/fonte placement is handled, leaving the mutation profile inferable rather than declared.

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 tight bullets, front-loaded with the normative standard and then the mode decision, with zero filler. Slightly under-informative rather than verbose, but structurally efficient.

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?

The output schema means return values need not be described, and the tool's purpose is clear, but five of six parameters are undocumented in both schema and description. For a formatter whose correctness hinges on 'source' and 'table_number' conventions, an agent cannot reliably call it without guessing.

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% across 6 parameters, yet only 'category' is explained in the description. The ABNT-specific parameters 'source' and 'table_number' — the ones an agent is most likely to misuse, including the allowed integer-or-string duality — get no explanation at all, and title/headers/rows are not characterized either.

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 (format data to IBGE/ABNT table norms) and enumerates the exact output formats produced: Markdown, LaTeX booktabs, Typst. It clearly separates the two output modes ('tabela' vs 'quadro'). It stops short of distinguishing itself from the sibling format_figure or from audit_illustrations_and_tables, so it is clear but not fully sibling-differentiated.

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 gives real selection guidance for the 'category' enum — numeric/statistical data goes to 'tabela' (open side borders), textual/qualitative data goes to 'quadro' (closed frame). However, it offers no guidance on when to use this tool rather than format_figure or the table-auditing sibling, so usage is implied only at the parameter level.

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 does disclose the enforceable output rules (single paragraph, 3rd person, 150–500 words, keyword punctuation) and hints at a word-range evaluation step, which is useful. It never says whether this is a pure read/generation operation or writes a file, nor what happens when the input falls outside the 150–500 range, so mutation/error behavior remains unclear.

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 front-loaded and the four bullet points are terse and each carries a distinct constraint. No filler or repetition, though the bullets describe output format rather than the missing input guidance.

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 not be explained, and the formatting rules are thorough. However, with six required, undescribed parameters and no annotations, the definition leaves the agent guessing about what content each input should contain and how strictly the word range is enforced — a real gap for a 7-parameter 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 description coverage is 0% across 7 parameters, so the description must compensate and largely does not. It covers only `language` (pt vs en) and `keywords` (semicolon-separated, period-terminated), leaving context, objective, methodology, results, and conclusion — five of six required inputs — completely undocumented in both schema and 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?

States a specific verb and artifact: generates a Resumo/Abstract following NBR 6028:2021, with the format rules enumerated. It is clearly distinguishable from any sibling (none of the others produce abstracts), though it never names a sibling or explicitly says 'this is not a citation/formatter tool'.

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?

Usage is only implied — an agent can infer it is the tool for producing an abstract from drafted research content. There is no explicit 'use when' statement, no mention of prerequisites (e.g. content must already exist), and no exclusions or alternatives among the many academic siblings.

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?

Sem anotações, a descrição carrega toda a responsabilidade e, de fato, informa os efeitos colaterais relevantes: criação de dois arquivos, cópia do logo e aprendizado automático a partir do PDF modelo. Faltam as semânticas de idempotência: se sobrescreve um spec existente, se falha ou se faz merge.

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?

O núcleo (inicializar os arquivos no projeto) vem primeiro, e as três camadas em bullets organizam bem o conteúdo. Há alguma densidade de jargão interno ('SDD', 'Camada 1/2/3'), mas a extensão é proporcional às informações fornecidas.

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?

Há output schema, portanto não é preciso descrever o retorno, e as camadas dão uma boa ideia do conteúdo gerado. Ainda assim, para uma ferramenta de escrita com 15 parâmetros, sem anotações e com cobertura de schema nula, faltam detalhes sobre sobrescrita, permissões e formato dos dados esperados, o que limita a completude.

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?

Com 15 parâmetros e 0% de cobertura no schema, a descrição deveria compensar, mas só aborda `research_problem`, `general_objective`, `specific_objectives` (OBJ-XX), `planned_chapters`, `sample_pdf_path` e `logo_path`. `project_path`, `author`, `course`, `advisor`, `institution`, `document_type`, `min_references` e `methodology_summary` não são explicados.

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?

A descrição começa com um verbo específico ('Inicializa') e um recurso concreto (o manifesto de Especificação Científica), além de nomear os artefatos gerados ('abnt.spec.json' e 'SPEC.md'). Isso a distingue implicitamente de `audit_research_spec`, que audita o mesmo artefato, embora a diferenciação não seja explicada com palavras.

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?

Não há indicação explícita de quando usar esta ferramenta, de quando não usar nem de pré-requisitos, como a necessidade de o projeto já existir. A sobreposição com `scaffold_academic_project` (que também cria estrutura de projeto) não é resolvida.

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 carries the burden. 'Extrai' implies a read-only extraction, and the 1-indexed page selection is disclosed, but nothing is said about missing-file behavior, performance on large PDFs, or what 'dados estatísticos' concretely means. The output schema covers return values, lowering the bar.

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 sentences, front-loaded with the purpose before the page-selection detail. Almost no waste, though 'dados estatísticos' is vague enough to dilute the first sentence slightly.

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?

The presence of an output schema removes the need to explain returns, and the description covers purpose and page selection. It stops short of differentiating from the many sibling audit/structure tools an agent must choose between, which is the key gap given this crowded toolset.

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 that pages can be specific pages or ranges and that indexing is 1-based, covering pdf_path, pages, start_page, and end_page implicitly. It does not clarify whether the pages array is mutually exclusive with start/end range, leaving a real ambiguity.

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 and resource ('Extrai o texto e dados estatísticos de um PDF acadêmico'), which is clear. It distinguishes itself somewhat from siblings like audit_illustrations_and_tables by focusing on text/statistical extraction, though it does not name any sibling explicitly.

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 phrase 'para fins de revisão e auditoria' gives an implied context, and page selection is described. However, it never states when to prefer this over siblings such as check_structure or audit_illustrations_and_tables, leaving the routing decision to inference.

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 burden and it does disclose the creation set and the two conditional enrichment paths (university pattern extraction from PDF, logo copying). However, it is silent on the most consequential behavior: what the `overwrite` parameter does to pre-existing files, whether the operation is destructive, and whether any external/permission requirements apply.

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 is front-loaded in the first clause, followed by a tight bullet list of artifacts and conditionals. No filler sentences, though the bullets could surface the required-vs-optional distinction more economically.

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 not be described, but for a 15-parameter bootstrap tool with no annotations and 0% schema coverage the description omits the overwrite semantics and the purpose of most authoring parameters. An agent could call it correctly only for the three required fields and would be guessing on everything else.

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% across 15 parameters, so the description must compensate and only does so for sample_pdf_path and logo_path (plus an implicit nod to `format` via main.typ/main.tex/main.md). Ten-plus parameters — project_path, title, author, course, advisor, institution, document_type, overwrite, and the research_problem/objectives/methodology group — get no explanation of their effect on generated output.

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 concrete verb and resource (initializes the complete directory/file tree of an academic project) and enumerates the artifacts produced: capitulos/, figuras/, abnt.spec.json, SPEC.md, referencias.bib, and the main file in the chosen format. It is clearly distinguishable from check_structure or compile_tcc, though it never names a sibling explicitly.

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 never says when to use this rather than init_research_spec, check_structure, or audit_research_spec, nor does it state prerequisites (does the project_path need to exist? empty?). The conditional clauses ('Se sample_pdf_path for fornecido...') describe behavior, not usage selection, so the agent is left to infer this is a first/bootstrap step.

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 behavioral burden. It does usefully disclose that only open databases (Crossref, SciELO) are searched and that matching happens on DOI, title and abstract, which signals a read-only, public-data operation. It says nothing about result ordering, pagination, rate limits or what happens when a source is unavailable, which matters for a tool with zero annotation coverage.

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 sentences, front-loaded with the verb, resource and sources before the use case. Nothing is redundant. The second sentence is generic but earns its place as the only usage signal in the description.

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 not be explained. The description covers sources, searchable fields and a use case, but for a multi-source search tool with no annotations it omits result ordering/merge behavior across Crossref and SciELO and the effect of `limit`. Adequate but with clear gaps.

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%, so the description must compensate and it partially does: naming Crossref and SciELO explains the `source` enum values, and 'por DOI, título e resumo' clarifies what the required `query` string is matched against. The `limit` parameter (default 5) is never mentioned, leaving one of three parameters undocumented in both schema and 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?

States a specific verb (busca) plus resource (artigos científicos recentes) and names the two data sources (Crossref, SciELO) and the fields searched (DOI, título, resumo). An agent immediately knows this is a bibliographic search tool. It does not explicitly contrast itself with sibling fetch_bibtex_by_doi, so it falls 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 second sentence ('Útil para embasar fundamentação teórica e capítulos de revisão bibliográfica') gives a use-case context, so the purpose-stage of a literature review is implied. However, there is no explicit when-not guidance and no routing to alternatives such as fetch_bibtex_by_doi for known DOIs or validate_citations for verification. Usage is implied rather than directed.

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 behavioral burden. It discloses meaningful behavior: checking alignment between Introduction, Specific Objectives, and Conclusion, using abnt.spec.json if present, calculating scores, and generating defense questions. However, it does not state whether the tool only reads files, whether it writes outputs, permission requirements, or other operational constraints.

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 description is short, front-loaded, and organized as two bullet points. Each sentence adds useful information about what the simulation evaluates and produces, with no wasted wording.

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 not be explained in detail. The description covers the tool's purpose and main behavior, but with no annotations and 0% schema description coverage, it does not fully specify input expectations or operational constraints. It is adequate but incomplete for a complex simulation 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 description coverage is 0% and the only required parameter, project_path, is not described in the description. The mention of abnt.spec.json hints that project_path is a project directory containing that file, but the description does not explain path format or expectations, leaving significant input ambiguity.

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 and resource: it executes an examining-board simulation for TCC/dissertation/thesis/article. It also names concrete operations (alignment evaluation, axis scoring, defense questions), making the purpose clear, though it does not explicitly differentiate itself from siblings such as check_structure or audit_research_spec.

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 implies use during defense preparation by mentioning 'defesa oral' and academic work types, but it gives no explicit when-to-use guidance or alternatives. The agent can infer the context, but selection versus similar academic auditing tools is left implicit.

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 well: 'auditoria' frames it as a diagnostic, and it discloses the three source formats (LaTeX, Markdown, Typst) and the three defect classes it reports. It stops short of stating that no files are modified or how it behaves when no .bib is found, so the safety profile is inferred rather than declared.

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-loaded with the core verb, then four tight bullets that each add non-redundant information. No filler; the only minor cost is that it spends its length on output scope while spending none on the inputs.

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 not be explained, and the defect taxonomy is well covered. But for a two-parameter tool with zero schema documentation, the description should say what project_path points at and when bib_path must be supplied; that gap is what holds this to adequate.

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 explained anywhere in the description. The phrase 'entre o texto e as referências' hints that one path is the project and one is the bibliography, but the meaning of bib_path's null default (auto-discovery? skip the orphan check?) is left entirely unresolved — a real risk of misuse.

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 — a cross-audit between the document text and its references — then enumerates exactly what it checks (orphan citations, uncited .bib entries, uppercase surnames violating NBR 10520:2023). That enumeration distinguishes it from siblings like clean_bibtex_file (which repairs) and format_citation (which formats a single citation).

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?

Usage is implied by the listed checks: an agent can infer it should call this before submission to find unresolved or uncited references. However, there is no explicit when-to-use statement, no mention of prerequisites (must a .bib already exist?), and no guidance on when to pass bib_path versus relying on discovery.

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