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 that insertion triggers page regeneration (a meaningful side effect), but omits whether a chapter can be overwritten, how antes_de/depois_de affect placement conflicts, or any authorization requirements.

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 and side effect in the first sentence, followed by value enumerations. The type and media lists are dense but each item is a valid input value, so they earn their place rather than being 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?

For a tool taking a nested chapter object with no output schema and no annotations, the description supplies useful content vocabulary and a structure reference, but leaves the ordering semantics (antes_de/depois_de) and return/response behavior unaddressed, so it is only partially 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 only 25% (just the nested capitulo object), and the description compensates well for that object by enumerating valid 'type' values and cinema media options plus the groups/meters/callouts structure. It says nothing, however, about projeto, antes_de, or depois_de, leaving the ordering parameters entirely 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+resource: 'Insere um capítulo no spec' (inserts a chapter into the spec), and discloses the side effect 'regera a página'. This clearly distinguishes it from siblings like ajustar_capitulo (adjust) and adicionar_modulo (add module), though it never names them 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?

Usage is implied rather than stated: the reference hint 'Use um momento (detalhar_momento) como referência da estrutura' points the agent at the right companion tool for building a chapter body. However, there is no guidance on when to add versus adjust an existing chapter, nor prerequisites or failure conditions.

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 implies a write ('Acrescenta'), but does not state permission requirements, whether duplicate modules are allowed, how antes_de/depois_de ordering behaves, or what the call returns. The closing note about demo forms is a minor honesty caveat but not the mutation behavior 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?

The verb and resource are front-loaded, but the middle is a single enormous em-dash parenthetical enumerating every module. That enumeration earns its place as an enum substitute, yet the run-on structure is hard to parse and the trailing sentence about demo forms feels tacked on.

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?

A mutation tool with no annotations, no output schema, 5 parameters at 0% coverage, and a nested 'opcoes' object requires more than this. Ordering parameters, permission/side-effect behavior, and opcoes structure are all unaddressed, leaving meaningful gaps for correct 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 coverage is 0%, so the description must compensate. It substitutes for a missing enum on 'modulo' by enumerating all valid values and hints at 'opcoes' keys (title, groups, slots, items, tiers, products), which is genuinely useful. However, it leaves 'projeto', 'antes_de', and 'depois_de' entirely unexplained, so 3 of 5 parameters remain 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 clear verb+resource ('Acrescenta um módulo que o cliente paga') and then enumerates the valid business module types, which concretely scopes what 'módulo' means. It is distinguishable from siblings like adicionar_capitulo or atualizar_motor, though it never explicitly contrasts itself with listar_segmentos_e_modulos. Clear and specific overall.

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 explicit when-to-use, when-not-to-use, or alternative guidance. The reader must infer that this mutates a project by adding a billable module. No sibling (e.g. listar_segmentos_e_modulos to discover modules) is named as a prerequisite 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses that the page is regenerated, that index.html gets an automatic backup, and precise deep-merge semantics (null deletes a key, lists are replaced). It does not disclose the destructive nature of 'remover' or move ordering behavior, but the merge rules and backup are genuinely useful behavioral detail.

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 the merge rules and illustrative examples. The examples are dense but earn their place by demonstrating nested-object mutations that the schema cannot express. No filler sentences.

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 7-parameter tool with nested objects, no annotations, and no output schema, the description covers editing/regeneration/merge well but omits the semantics of move (mover_antes_de/mover_depois_de), remove (remover), and duplicate (duplicar_como) operations that are central to the tool's stated purpose. Fill-in-the-gaps guidance is partial.

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 only 29%, so the description must compensate. It thoroughly explains the most complex parameter, 'alteracoes', with concrete examples of deep-merge behavior. However, projeto, remover, duplicar_como, mover_antes_de and mover_depois_de receive no explanation in the description beyond the title's move/remove hint.

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: it edits a chapter in experience.json and regenerates the page. Combined with the title (adjust/move/remove), an agent understands the core operation. It is distinguishable from adicionar_capitulo, though that contrast is not made 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?

There is no explicit when-to-use / when-not guidance. The title hints at move/remove but the description never states the conditions under which an agent should choose this tool over adicionar_capitulo or ajustar_site. The reader must infer usage from the operation name.

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 a genuinely useful side effect: the tool regenerates output while preserving customizations in css/site.css and only updating the token block. That is meaningful transparency, but it says nothing about permissions, reversibility of changes, or which fields are destructive.

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 sentence with no filler, but it is a dense run-on list that is hard to parse, and the important regeneration/preservation caveat is buried in a trailing parenthetical. Front-loading the mutation intent works; the enumeration could be structured better.

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 15-parameter mutation tool with nested objects, no annotations, no output schema and low schema coverage, the description does name all facets and note the regeneration behavior. However it leaves most parameter semantics and the response/effect surface unexplained, so it is only partially adequate for the tool's complexity.

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 only 27%, so the description must compensate. It names every adjustable facet (paleta, tipografia, cursor, grão, vinheta, suavidade do scroll, som, loader, portão de som, índice, pré-carregamento), which maps to most of the 15 parameters, but it gives no value semantics or acceptable ranges beyond what the schema already documents for the few annotated fields.

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 (muda) and enumerates the exact facets it controls — palette, typography, cursor, grain, vignette, scroll smoothness, sound, loader, sound gate, index, preload — plus the regeneration step. An agent can distinguish this site-wide adjustment tool from ajustar_capitulo or criar_site. It stops short of explicitly naming a sibling, so 4 rather than 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?

No guidance on when to use this versus siblings like transformar_site or ajustar_capitulo, and no stated prerequisites (e.g. that an existing project/site must exist). The usage is only implied by the verb 'muda' and the required 'projeto' parameter.

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?

Annotations already declare readOnlyHint=true, and 'Não altera nada' merely echoes that. However, with no output schema the description adds real behavioral value by disclosing exactly what is detected and returned (section classification, immersion map, recommended impossible moment), letting an agent predict the response shape.

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?

One dense sentence, but the read verb and the 'não altera nada' guarantee are front- and back-loaded sensibly, and the long enumeration earns its length because no output schema exists to carry the return contract.

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 no output schema and only one required parameter, the description covers inputs, the read-only contract, and the returned analysis comprehensively. The gap is the undocumented 'intensidade' parameter, which is the only piece an agent must guess at.

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 67%, so the schema already documents origem and pagina. The description reinforces the accepted origin types but says nothing about 'pagina' defaults or what the 'intensidade' enum (sutil/media/alta) controls, leaving the enum parameter unexplained.

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

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

States a specific verb ('Lê') and resource ('um site já feito') and enumerates the accepted input forms and the full return set (marca, idioma, SPA detection, paleta, MAPA DE IMERSÃO). This clearly separates it from siblings like criar_site, transformar_site and verificar_site.

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 when it applies by listing accepted origins (folder, .html, React/Vue/Vite build, URL), but it never states when to prefer it over transformar_site, verificar_site or ajustar_site. Usage context is inferable but not 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?

The annotations already declare readOnlyHint=true, so safety is covered; the description adds value by disclosing what the inspection actually reports (static head/tail segments, hard cuts, instant change concentration) with model-specific context (Kling vs Seedance behavior). No return format or pagination detail is given, but the output set is well conveyed.

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 verb and tightly packed into two sentences with no filler. The parenthetical asides about Kling/Seedance are dense but they earn their place by explaining why the static-segment metric matters.

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 output schema, the description carries the burden of explaining what the tool returns, and it does so by listing the analysis dimensions. For a read-only, two-parameter inspection tool this is nearly complete; only the response shape/first required param are untouched.

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?

Both parameters are fully documented in the schema (100% coverage), so the description need not restate the video path or projeto folder. It adds no syntax or path-format detail beyond what the schema already provides; baseline 3 is correct.

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 ('Inspeciona um clipe') and enumerates exactly what is measured: duração, resolução, fps, trechos parados, cortes secos, concentração de mudança. This distinguishes it from extraction siblings like extrair_frames or folha_de_contato, though 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?

Gives a clear usage context: 'Inspeciona um clipe antes de fatiar' and 'Use para escolher o melhor take/modelo.' The trigger is explicit, but no exclusions or named alternatives tell the agent when not to use it.

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 provided, the description carries the full burden and does well: it names exactly which artifacts are reinstalled and explicitly excludes index.html, css/site.css and js/site.js, so the agent knows what will and will not be overwritten. It omits whether existing customizations are backed up or lost, and what a failure looks like, keeping it short of a 5.

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, zero filler, front-loaded with the action and the affected files, followed by the explicit exclusions. Every clause 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 mutation tool with no annotations and no output schema, the description covers scope and exclusions but leaves gaps: no indication of the parameter's format, reversibility/backup behavior, or what success returns. It is adequate but not complete for the risk profile of an overwrite operation.

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 single 'projeto' parameter, so the description must compensate. It partially does: '(ou num site transformado)' signals that 'projeto' can refer to a project or a transformed site, but it never states whether the value is a path, slug, or ID.

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 (reinstala) and the exact resources touched (imersao/imersao.js, imersao.css, Lenis), which clearly separates it from sibling site tools like ajustar_site or transformar_site. It stops short of naming a sibling or explicitly contrasting with them, so it is clear but not fully differentiated by comparison.

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 'com a versão deste MCP' implies the trigger is syncing the project's engine to the current MCP version, and '(ou num site transformado)' hints at the applicable target contexts. However, there is no explicit when-to-use vs when-to-use-an-alternative guidance relative to siblings such as ajustar_site or transformar_site.

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 discloses the solo-mode URL form (?solo=id:p), device modes, and reduced-motion support, but says nothing about return format (image payload?), permissions, or any side effects. For an unannotated capture tool this is a significant gap.

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 core action and the scroll/section scoping before the workflow hint. Dense but efficient, with 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?

With 8 parameters, no annotations, and no output schema, the description is too thin. It does not explain the majority of parameters, the return value, or the relationship between url/pagina/projeto and the capture target, leaving an agent under-equipped to invoke it 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?

Schema description coverage is only 25% (only p and capitulo are documented). The description maps loosely to p (scroll point), capitulo (section by id), and dispositivo (desktop/celular/reduzido), but leaves url, altura, largura, pagina, and projeto entirely unexplained 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 ('Fotografa') and resource (a chapter fixed at any scroll point, or a section by id), with the device modes enumerated. It differentiates itself somewhat from capture-adjacent siblings by scoping to scroll positions and solo mode, though it never spells out what the output actually is.

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 closing sentence gives a workflow ('veja, descreva o que sente, aplique nota_de_direcao, capture de novo') that ties this tool to the sibling nota_de_direcao in an iterative loop. However it gives no explicit when-to-use vs alternatives (e.g., versus extrair_frames or folha_de_contato) and no when-not conditions.

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?

There are no annotations, so the description carries the full burden. It does disclose valuable behavior beyond structure: it returns a markdown briefing, an experience.json spec, and an asset plan with estimated cost, and it states the side effect that providing 'projeto' writes BRIEFING.md, experience.json and plano-de-assets.json to disk. That said, it omits permissions, idempotency, failure modes, and whether the file write is additive or overwriting.

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 verb and resource, and the return/side-effect facts are stated compactly. However, the long arrow chain (enquadramento → técnica → STILLS → FILMS → ...) consumes most of the text with jargon that conveys little to a selecting agent, so it is dense without being efficiently informative.

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 high-complexity tool with 23 params and no output schema, the description does usefully enumerate the three returned artifacts, which partially compensates for the missing output schema. But the 39% of undocumented parameters, the nested objects (paleta, visual, tipografia, itens), and the three enums are left entirely to the schema, so the definition is not 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?

With 23 parameters at 61% schema description coverage, roughly a third of inputs are undocumented. The description adds essentially no per-parameter meaning — it enumerates pipeline stages rather than explaining inputs like visual, modulos, gerador, or momento. An agent gets no help resolving the enums or nested objects from the prose.

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 ('Reconstrói, para qualquer marca, a espinha dos prompts') and enumerates the pipeline stages it assembles, so the agent can tell it produces a briefing rather than a site. It is clear on what the tool is, but it does not name or differentiate itself from siblings like criar_site or planejar_assets; the only routing hint ('para isso use criar_site') lives in the schema, not the description.

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?

'Para qualquer marca' implies broad applicability but gives no when-to-use condition, no prerequisites (e.g., that marca/descricao are required), and no exclusion telling the agent to prefer another sibling. The criar_site pointer is buried in the 'projeto' schema field, so the description itself offers no usage 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 burden and does well: it discloses that the site is generated working with fallbacks (photos/procedural), that it auto-switches to real scrub once extrair_frames registers frames, and (via parameter docs) that sobrescrever backs up index.html and preserves css/js. It stops short of stating permissions, failure modes, or what happens when the project folder already exists.

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 concrete deliverables, then the spec-source order, then fallback behavior—a sensible ordering. It is dense but appropriate for a 26-parameter generator with no output schema, and no sentence is pure 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?

For a complex scaffolding tool with nested objects and no output schema, the description covers the essential agent questions: what gets generated, how inputs are prioritized, and how the fallback/upgrade path works. It omits some detail on the many optional style/briefing parameters, but nothing critical for invoking it correctly is missing.

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 65%, above the baseline threshold, so the schema already documents most of the 26 parameters. The description adds the important spec-source precedence rule tied to the 'spec' parameter and names extrair_frames, but it does not clarify the many uncovered parameters (cidade, email, telefone, paleta, cursor, etc.), so it stays at the baseline.

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 action ("Gera o projeto completo") and then enumerates the exact artifacts produced: index.html, css/site.css, js/site.js, the imersao/ engine, local server, launchers and README. The scope (full from-scratch scaffold, 'do zero') is clear enough to distinguish it from siblings like ajustar_site or transformar_site.

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 explains the spec resolution precedence (spec → briefing fields → experience.json) and notes the dependency on extrair_frames for real scrub, which is useful operational context. However, it never says when to choose this tool over alternatives such as criar_briefing or ajustar_site, and gives no exclusions or preconditions, so usage 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?

Annotations only declare readOnlyHint=true; the description adds substantial behavioral content by enumerating the returned payload (stills, films with pre-filled English prompts, linked instruments, interactions, sound, background action, suggested chapters, tips). With no output schema, this enumeration is the only source of return-value information and it earns real credit.

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 with the verb and resource first, followed by a dense but purposeful enumeration. Every listed item adds information; 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?

Given nested objects, six parameters and no output schema, the description adequately conveys what is returned and the read-only nature. It falls short on usage context and on clarifying the input parameters that customize the prompts, so it is viable but 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?

The description never addresses parameters, though six exist. Schema coverage is 67%, leaving marca and idioma undocumented anywhere, and the description does not compensate. Only 'assunto' is faintly echoed via 'já preenchidos com o seu assunto'.

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 ('Mostra tudo de um momento') and enumerates the returned content (stills, films, instruments, interactions, sound, background, chapters, tips), so an agent knows exactly what this retrieves. It does not, however, differentiate itself from sibling detail/analysis tools like capturar_capitulo or analisar_site.

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 offers no when-to-use guidance, prerequisites, or alternatives. It does not say when to call this versus listar_momentos (only referenced in the schema) or any other sibling.

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 provided, the description carries the full burden and does well: it discloses automatic trimming of still segments, hard-cut warnings, concrete output paths and formats, and the side effect that the site will start using the real scrub immediately. Gaps remain on overwrite behavior (does re-running replace frames/<nome>/?) and permissions/runtime (interpolation is called 'lento'), but the side-effect surface is unusually well surfaced.

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 sentences, front-loaded with the pipeline purpose and then the outputs; every clause carries factual content rather than filler. It is dense and jargon-laden ('prompt validado', 'imersao.manifest.json'), and the middle sentence strings five distinct side effects together, which slightly hurts 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?

For a 14-parameter, no-output-schema, no-annotation tool, the description covers the essential unknowns: what gets written where, which auxiliary artifacts appear, and that the site picks up the scrub automatically. It stops short of covering failure modes, permissions and whether existing frame folders are replaced, but an agent has enough to invoke it 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?

Schema description coverage is 93%, so the schema already documents nearly every one of the 14 parameters. The description adds concrete defaults that map to quadros, largura and qualidade ('~200 frames (1600–1920 px, JPEG q3)') and confirms the videos chaining semantics, but adds nothing for aparar, inicio, fim, interpolar or mp4_scrub beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 concrete verb+resource (cut a video into ~200 frames) and enumerates the full set of artifacts produced (frames/, fallback MP4, poster, imersao.manifest.json), so the agent knows exactly what the tool does. It does not, however, distinguish itself from close siblings such as extrair_quadro, analisar_video or folha_de_contato, which likely overlap in the video-to-image space.

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 phrase 'Pipeline completo do prompt validado' implies where the tool sits in the workflow (the step after a validated visual prompt), and the note about multiple videos forming chained clips hints at the batched mode. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools, so selection is left largely 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 must carry the full behavioral burden. It does disclose the core mutation (writes a JPEG to disk) and the output format, plus the chaining behavior of using the last frame. It omits overwrite/error behavior and any permission or timing constraints, so the disclosure is partial.

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 tight sentences with no filler, and the what-it-does statement is front-loaded ahead of the chaining tip. The structure is efficient, though the chaining sentence could be trimmed without loss.

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 write tool with no output schema and 40% parameter coverage, two sentences is thin. Several parameters go undocumented, and there is no mention of output path semantics or failure modes, so an agent is left guessing about width and project inputs.

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 only 40%, so the description should compensate. It clarifies the frame-selection semantics that map to 'posicao' (though the schema already documents those values) and implies 'video'/'saida', but it says nothing about 'largura' (width) or 'projeto', which remain undocumented in both places.

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 gives a specific verb+resource ('Salva ... um quadro ... de um vídeo como JPEG') and specifies which frames can be selected (first, last, or a time in seconds). It is clear on its own, but it never distinguishes itself from the close sibling 'extrair_frames' (plural), which an agent could easily confuse with this single-frame 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?

It provides one concrete workflow – use the LAST frame as start_image of the next clip to chain a continuous journey – which is genuinely helpful guidance. However, it gives no when-not condition and no explicit routing between this tool and 'extrair_frames' or 'analisar_video', leaving sibling selection 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 only readOnlyHint=false provided, the description carries the burden and does disclose that it renders a sheet per video and returns images plus an analysis of each clip, plus the output-directory default. It omits cost/time characteristics of rendering multiple videos and any write/permission details, so it is only partially transparent.

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 core action and purpose; the model examples add specificity without much bloat. Slightly dense but 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?

For a mutation/generation tool with 5 parameters, 20% schema coverage, no output schema, and minimal annotations, the description should explain grid controls, projeto behavior, and multi-video handling. It only states that images and per-clip analysis are returned.

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 20% (only saida_dir is documented) across 5 parameters. The description implies a grid but never explains linhas, colunas, videos array semantics, or projeto, so it fails to compensate for the documentation 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?

States a concrete verb ('Gera') plus resource ('folha de contato / grade de quadros') and its purpose of comparing takes or models, so an agent knows what it produces. It does not, however, distinguish itself from siblings like extrair_frames or extrair_quadro, leaving the boundary between them implicit.

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 use case is implied through 'para comparar takes ou modelos ... e escolher o que melhor espalha a mudança', which gives context for when the tool fits. But there is no explicit when-to-use/when-not guidance nor any routing to alternative siblings, so the agent must infer.

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?

readOnlyHint=true already tells the agent this is a safe read with no mutation, and the description's 'Devolve' is consistent with that. The description's extra content primarily restates the returned sections listed in the enum rather than disclosing behavior beyond the annotation, so a baseline 3 is appropriate.

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 verb and kept to two sentences. The long content enumeration is dense but each item maps to a real returned section, so it earns its place, though it borders on a list dump.

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-parameter, read-only reference tool with no output schema and covered safety annotations, the description tells the agent what the guide contains and when to read it. It is largely complete, missing only explicit secao/default semantics.

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 single 'secao' parameter is undocumented in the schema. The description names the section categories (princípios, anatomia, resgate, power-ups, etc.) that map onto the enum values, adding some meaning, but it never explains that secao selects one section nor how the default ('tudo') behaves, so it only partially compensates.

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 ('Devolve') plus resource ('a metodologia') and enumerates the exact content blocks returned (princípios, anatomia, lições, checklist, fluxo), so an agent knows precisely what it gets. It is clearly unlike any sibling such as planejar_assets or revisar_prompt_visual, which act on a project rather than return a reference guide.

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 de projetar ou revisar uma experiência' gives a clear when-to-use trigger. It does not, however, name an exclusion or an alternative tool, so it stops short of full routing 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?

readOnlyHint=true already establishes this as a safe read, lowering the burden. The description adds domain context by revealing the catalog's taxonomy, but says nothing about result size, ordering, or whether the list is paginated/truncated, which matters for an enumeration-style endpoint.

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?

Purpose is front-loaded in the first clause, which is good. However, roughly nineteen enumerated moment types consume most of the text; the taxonomy has informational value but is longer than needed to select and invoke the tool.

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-optional-parameter read-only listing with no output schema, the description covers what it returns and how to narrow it. The remaining gap — the shape/count of returned items — is minor and largely inferable from the enumeration.

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 'filtro' parameter is documented nowhere else, so the description must carry it. It does explain the parameter is a free-text filter and gives two example values, but does not say what fields the text is matched against (moment name, segment, keywords) or whether matching is partial/case-insensitive.

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 ('Lista os momentos impossíveis catalogados') and enumerates the catalog contents, so an agent knows exactly what comes back. It does not differentiate itself from the sibling 'detalhar_momento' (list vs. detail), 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 description tells the agent it can filter by text and gives concrete filter examples ('joalheria', 'restaurante'), which implies how to narrow the listing. It never says when to use this tool instead of 'detalhar_momento' or 'recomendar', and there are no exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true, so the read-only safety profile is covered without description help. The description does add useful context by sketching the returned shape (segments with their moments and modules, plus all modules), but says nothing about volume, ordering, permissions, or whether the list can be empty.

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 sentence with no filler, front-loading the primary resource (segments) before the secondary one (modules) and closing with the downstream consumers. Nothing needs to be cut or reordered.

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 output schema, the description appropriately describes what comes back rather than what goes in, and a zero-parameter read-only tool needs little else. It could go further on ordering or how to correlate modules with segments, but it is sufficient to invoke 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; a baseline of 4 applies. Schema coverage is 100% and the empty object schema is fully self-consistent with 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?

States a specific verb ("Lista") and two concrete resources: business segments (with their moments and modules) and all available business modules. It is distinguishable from siblings like listar_momentos and detalhar_momento, though it does not explicitly contrast itself with listar_momentos, which operates on adjacent data.

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 rather than spelled out: the description notes the modules are those "available for criar_briefing/adicionar_modulo," which hints at when the output is consumed. There is no explicit when-to-use/when-not statement and no comparison against sibling listers.

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?

The description is consistent with readOnlyHint=true: it measures and returns a value without mutating anything. Beyond the annotation it adds that the returned number is directly consumable by data-im-offset and that stacking requires same-image edits, but says nothing about failure modes (unaligned/incompatible plates) or output shape.

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 tight sentences with the core action front-loaded and the constraint placed second. No filler, though the parenthetical '(raio-X, térmica, depois)' is slightly cryptic without context.

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 three parameters at 0% schema coverage and no output schema, the description is only partially sufficient: it explains the concept and the intended downstream use of the result, but leaves the input formats and the shape/units of the returned offset undefined.

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 carry parameter meaning and largely does not. It obliquely maps 'placa-base' and 'placa-edit' to the base/camada inputs but never defines the string format (path, ID, name), and the 'projeto' parameter is left entirely unexplained.

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

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

States a specific verb and resource: it measures the displacement between the base plate and an edit plate, and says what the result is for (data-im-offset of the lens). This is enough to distinguish it from the site/moment/module siblings, which is the main risk given the tool sits in a very different domain.

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 provides a precondition ('plates only stack if they are edits of the same image'), which implies when the tool is valid, but never says when to reach for it versus not, nor names any alternative or follow-up tool. Usage remains inferred rather than stated.

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 the important mutation behavior: aplicar=true alters the spec and regenerates the page. It still omits permissions, reversibility, whether the default is non-destructive, and what the diagnosis output looks like, so disclosure 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?

Two sentences with the action summary front-loaded, but the eight quoted example phrases consume a large share of the text. The examples teach the expected input style, yet the same guidance could be conveyed more compactly.

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 4-param mutation tool with no annotations and no output schema, the description covers the core mode of operation, key parameters, and targeting. It still leaves the response/diagnosis format, aplicar's default, and the scope of spec mutation unspecified, so it is adequate but 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%, so the description must compensate. It meaningfully explains nota (via example phrases), aplicar (true -> rewrite spec + regenerate), and capitulo (target a single chapter), but says nothing about projeto. Three of four parameters gain context, which lifts it above the raw schema without fully covering the 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 description conveys that the tool takes a free-form 'nota' (sentiment/direction), diagnoses it, lists concrete adjustments, and with aplicar=true rewrites the spec and regenerates the page. The action set is identifiable, but the framing ('Dirija com sentimentos') is impressionistic and there is no explicit differentiation from siblings like ajustar_capitulo or ajustar_site, leaving the agent to infer boundaries.

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 real targeting guidance ('cite o capítulo... para mirar um só') and implies the operate/skip toggle via aplicar=true, and the example phrases model the kind of input expected. However it never states when to prefer this tool over adjuster siblings or the default behavior of aplicar, so usage is only partially specified.

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 return behavior (it lists servers still up), which partially substitutes for the missing output schema. However, it omits the disruptive/irreversible nature of stopping a server, permission requirements, or what happens to in-flight work.

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 well-formed sentence with the core action front-loaded and the scope qualifier compactly parenthesized. 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 one-optional-parameter stop tool with no annotations and no output schema, the description covers the action, scope, and return list adequately. It still leaves the destructive/side-effect profile and prerequisites unstated, which is the main remaining 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 lone parameter has no description, so the description must compensate. It does: the parenthetical '(ou todos, sem "projeto")' explains the omission semantics of the optional parameter, which the schema does not. It stops short of clarifying the expected identifier format for 'projeto'.

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 verb+resource: it stops a project's server, and clarifies the scope variant (project-scoped or all). This pairs clearly with the sibling servir_site, though the description never names that counterpart 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 tells the agent how to select scope operationally: pass a project to stop one server, or omit it to stop all. No explicit when-not or named alternative (e.g., servir_site) is given, but the invocation context is unambiguous.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description usefully adds that it produces only a plan — not an execution — and itemizes the plan's contents including estimated credit cost and follow-up extrair_frames commands. It does not contradict the annotation and adds real context beyond it.

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 dense sentence enumerating contents followed by a short usage sentence; the core purpose is front-loaded and nothing is padding. The enumeration is long but load-bearing for a plan generator with no output schema.

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 nine parameters, a nested visual object and no output schema, the description carries the return-content burden well by listing what the plan includes. The remaining gap is deeper per-parameter guidance, but what an agent needs to call it is largely present.

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?

With 33% schema description coverage the description should compensate, and it partly does: it clarifies that visual prompts must be filled in English and explains the gerador values (Higgsfield or other). But it maps mainly to outputs and leaves marca, produto, segmento, qualidade and acento unexplained.

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

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

States a specific verb and resource ('Gera só o plano de geração para um momento') and enumerates exactly what the plan contains (placa-herói, edits, filmes, prompts, custo). The 'só o plano' qualifier distinguishes it from execution tools, and it names the sibling extrair_frames whose commands it produces.

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 tells the agent to use it with the Higgsfield MCP (gerador 'higgsfield') or any other, giving integration context. However there is no explicit when-not guidance or direct comparison against alternative siblings for planning versus generating.

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 readOnlyHint=true, the safety profile is already covered by annotations, so the bar is low. The description usefully discloses what the tool produces (detected segment, recommended momento, modules, copy tone), which matters since no output schema exists. It adds no auth, rate-limit, or determinism context, so it earns a modest 3.

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 well-formed sentence that front-loads the input mechanism and then lists the outputs, with illustrative examples. No filler or redundancy.

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 recommendation tool with no output schema and 0% schema coverage, the description covers the input surface partially and sketches the output categories, but omits the 'segmento' parameter's role and gives no sense of the recommendation's format. 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 carry parameter meaning. It explains 'descricao' well with two concrete examples, but never addresses the 'segmento' input at all; in fact mentioning 'detecta o segmento' could be misread as an output. One of two parameters is left semantically undefined.

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 pair (detecta, recomenda) and concrete resources: the segment, the momento, business modules, and copy tone. An agent can distinguish it from siblings like listar_momentos or listar_segmentos_e_modulos, which merely enumerate rather than recommend. It stops short of naming those siblings explicitly, so it's clear but not maximally 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 trigger context is implied by 'A partir de uma descrição livre do negócio ou site' with example inputs, telling the agent to use it when it has free-text business input. However, there is no explicit when-to-use-this-vs-alternatives guidance and no exclusions, so the usage is only inferred.

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?

Annotations cover the safety profile (readOnlyHint=true), so the bar is lower, and the description goes beyond by disclosing the actual return payload: nota, problemas e versão melhorada. That is genuinely useful behavioral context, particularly in the absence of an output schema.

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 the verb and the audit target before the criteria list, and the criteria are compact comma-separated fragments rather than prose. It is a long list, but each item carries distinct content and nothing is redundant.

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?

It covers purpose, criteria and return shape, which is decent for a read-only auditor. But with 0% schema coverage on 4 parameters and no output schema, the omission of parameter meaning (modelo, assunto) leaves 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 description coverage is 0% across 4 parameters, so the description must compensate, but it only clarifies the tipo enum (placa=imagem, movimento=vídeo). It never explains modelo, assunto, or prompt, leaving three parameters semantically dark.

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 (audita) and resource (um prompt de placa para imagem ou de movimento para vídeo), and distinguishes the two modes. The purpose is unmistakable and clearly distinct from project/site siblings, though it doesn't explicitly name an alternative 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?

The description lists the audit criteria but never says when to invoke this vs alternatives, nor any preconditions (e.g. run before generating, after a failed render). Usage is only implied by the subject matter.

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: it discloses no-cache behavior, video support, session-bound lifetime, and the return shape (URL plus test shortcuts). It omits failure modes such as what happens if the port is already occupied or if a server is already running.

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 dense sentences, front-loaded with the action and followed by lifetime and return details; each sentence carries information. The parenthetical shortcut list is useful but makes the paragraph slightly heavy.

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 exists, and the description compensates by naming the return value (URL + test URLs). With no annotations, behavior is covered adequately for a server-start tool; the residual gap is the undocumented 'porta' 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 coverage is 0%, so the description must explain both parameters. It partially defines 'projeto' (project folder or transformed copy) but says nothing about the 'porta' parameter — the mention of the 'project's own port' is about the default, not about how the override argument behaves.

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 concrete verb+resource: it starts a local server for the project folder (or the transformed copy), with specific traits (project port, no cache, video support). It is clearly distinguishable from the sibling parar_site, though it never names that counterpart 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?

Gives real lifecycle context — the server lives only while the MCP is open, and abrir-site.bat/.command is the alternative for running it outside. However, it never says when to reach for this vs. the verification siblings (verificar_site, capturar_capitulo) that presumably depend on a running server.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing the content of the report (registered vs expected sequences, unfilled markers, port, last verification), but says nothing about permissions, cost, or staleness of the data.

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?

One dense sentence, front-loaded with the core action and followed by the concrete report contents. Nothing is wasted, though the list is packed tightly enough to read as a run-on.

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 output schema, the description carries the return-value burden and does so thoroughly by enumerating every reported field. The remaining gaps — how to identify the project and when to prefer this over sibling inspection tools — are minor for a one-parameter read 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 single required parameter 'projeto' is undocumented — the description only refers to 'um projeto' generically. It never clarifies whether the value is a project name, slug, ID, or path, so it fails to compensate for the schema 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?

States a specific verb+resource (mostra o estado de um projeto) and then enumerates exactly what state is surfaced: chapters, frame sequences registered vs expected, pending images, unfilled [[...]] markers, port, last verification. That enumeration separates it from siblings like verificar_site or analisar_site, though it never names an alternative 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 when-to-use guidance, no prerequisite, and no routing against the many sibling inspection tools (verificar_site, analisar_site, analisar_video, medir_alinhamento). Usage is only implied by the word 'status'.

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 so well: it discloses the non-destructive copy semantics, that forms remain functional, and that it emits IMERSAO.md plus a local server and launchers. It also describes the prologue and ancillary features that get injected. It stops short of stating permissions, failure modes, or idempotency 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?

Front-loaded with the single most important fact (a copy is made, original untouched) and then enumerates injected features and outputs. It is dense and long for a single paragraph, but nearly every clause carries information; the feature list could be trimmed without losing calls.

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 19-parameter tool with nested objects, no annotations, and no output schema, the description covers the essential behavior: what gets created, that the source is preserved, what artifacts are produced, and one cross-tool dependency. It leaves several parameters and the exact failure/permission 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 only 53% across 19 parameters, so the description must compensate but largely does not: most of what it says about prologue variants (particles, fragments, push-in, frame scrub) and sobrescrever duplicates the schema's own text. It does add a useful cross-tool note about running extrair_frames with name 'prologo' for frame scrubs, but many parameters (grão, vinheta, fonte_texto, max_paginas, fundo_capitulos) remain unexplained.

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

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

States a specific verb+resource (creates an immersive COPY of an existing site) and immediately delimits scope: the original is never touched. This cleanly distinguishes it from sibling criar_site, which builds a new site, and the emphatic 'CÓPIA' removes any ambiguity about what is produced.

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 makes the usage context clear — it targets an already-built site and accepts a folder, .html file, SPA build, or URL. However, it never explicitly names criar_site as the alternative for greenfield work, nor does it state when NOT to use this tool, so the agent must infer the routing from 'site já feito'.

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 a good job: it discloses that it launches a headless browser, drives the page through scroll/scrub positions, and returns a report plus screenshots of each chapter. It also implies a filesystem side effect ('todas ficam salvas em .imersao/verificacao'). It stops short of stating whether the site itself is mutated, runtime cost, or failure 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?

Front-loaded with the core action, and the long semicolon list is dense rather than padded — each clause names a concrete check. It is heavier than ideal for a single run-on sentence, but the length is justified by the breadth of the verification contract.

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 9-parameter tool with no annotations and no output schema, the description adequately conveys what is checked and that a report plus screenshots come back. However, it never explains the three undocumented parameters or what the report contains structurally, leaving an agent to infer input shape for 'pagina', 'screenshots' and 'dispositivos'.

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 67%, so the schema documents most parameters (pontos, capitulos, max_imagens, projeto, secoes). The description only loosely maps to parameters — the '10/50/90%' scrub points correspond to 'pontos' and 'screenshots de cada capítulo' to the screenshot output — but adds no syntax or format detail, and leaves 'pagina', 'screenshots' and 'dispositivos' undocumented in both places.

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 ('Abre o site num Chrome/Edge headless e confere') and then enumerates the exact verification checklist (loader, chapter scrub points, blank stage, console errors, 404s, leftover markers, live calculations, forms, muted audio, 390px mobile, reduced motion). This level of enumeration makes it functionally distinct from siblings like analisar_site or capturar_capitulo even without naming them.

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 via 'como manda o bloco VERIFY dos prompts validados', which signals it is a post-build validation pass. There is no explicit when-to-use/when-not guidance and no routing against alternatives such as analisar_site, capturar_capitulo or servir_site.

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