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 disclose a meaningful constraint — only apps pre-approved in config.yaml can be opened — which hints at a failure mode, but it says nothing about what happens when the name is not allowlisted, whether the app is brought to the foreground, or whether a handle is returned (the output schema covers the last part).

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 no filler; the constraint and the value examples both earn their place. Slightly compressed into one clause, but nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the one required parameter is illustrated. Still, for a launcher with no annotations, the description leaves the agent guessing about failure behavior for non-allowlisted names and about whether the call blocks or launches asynchronously.

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 for the single 'nome' parameter. The inline examples ('bloco de notas', 'calculadora', 'vscode') add real value by showing the expected value vocabulary, but matching rules such as case sensitivity, exact config key vs human-readable name, and whether aliases work 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?

States a specific verb ('Abre') plus the resource ('um app'), and names the source of truth ('liberado no config.yaml'). The examples ('bloco de notas', 'calculadora', 'vscode') make clear this is a desktop app launcher rather than the browser/window siblings (navegador_abrir, janelas_listar), though the distinction is only 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 phrase 'liberado no config.yaml' implies that this tool is only usable for allowlisted apps, which is useful scoping context. However, it never states when to choose this over navegador_abrir or janelas_listar, nor what to do if the desired app is not on the list.

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 whole behavioral load; it does disclose that the PR is created as a draft and that title/body are generated locally rather than by a service. It omits what happens on failure, whether an existing PR causes an error, auth requirements, and that pushing is an externally visible mutation.

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

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

Two short sentences with no filler; the primary action is front-loaded and the dry-run caveat follows immediately. Nothing needs to be trimmed.

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

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

An output schema exists, so return values need no explanation, but for a destructive, externally visible mutation with zero annotation coverage the description is thin on prerequisites and parameter meanings. It is adequate to attempt the call correctly but not to predict its side effects.

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 should compensate, but it explains only 'simular' and says nothing about 'pasta' (apparently the repository folder) or 'base' (target branch). Two of three parameters remain ambiguous from 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?

The description names a specific compound action — push the current branch and open a draft PR with a locally generated title and description — which is more than the name alone conveys. It is distinguishable from git_push and git_commit because of the PR-creation step, though it never explicitly contrasts itself with 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 one explicit usage rule is that simular=true performs a dry run showing the text without sending anything, which is genuinely useful. There is no guidance on when to prefer this over git_push plus a manual PR, nor any stated prerequisites (remote configured, authentication, clean working tree).

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 whole burden; it does disclose the most important trait, that the action must be gated on explicit user confirmation, and that it operates on a post-emergency-stop state. It omits whether release is reversible, what physical side effects follow, or what happens if the tool is called without consent, which are material for a hardware-affecting operation.

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

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

Two short sentences: the action and its trigger first, the consent requirement second. Nothing is redundant and the safety gate is not buried.

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

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

For a zero-parameter action with an output schema present, the description supplies the essentials: what it does, when, and the consent requirement. It is slightly thin on post-release behavior and failure modes, which matters given this affects physical hardware.

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 input schema declares zero parameters, so there is no parameter meaning to add and the baseline is 4. The description correctly implies no arguments are needed beyond the confirmation gate.

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 ('Libera' / release) and object ('o braço') plus the triggering condition ('depois da parada de emergência'), which is enough for an agent to identify the action. No sibling tool touches the arm or emergency stop, so differentiation is implicit rather than stated, which keeps it just below the top band.

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 clearly states the situation in which the tool applies (after the emergency stop, Ctrl+Alt+P) and a hard precondition (only with the user's OK). It does not name an alternative or say what to do if the user refuses, but no sibling overlaps this function, so no routing ambiguity is created.

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 discloses two important behaviors: the index refreshes itself (only changed files) and results include previously resolved decisions/errors stored via `lembrar`. What it omits is that auto-indexing implies a write side effect and any cost/latency characteristics of the first scan.

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

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

Three short sentences with the outcome stated first and the usage rule second; little waste. The trailing 'pasta: raiz do projeto' fragment is slightly awkward but still useful.

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 needn't be described, and the behavioral story is reasonably complete for a retrieval tool. However, the near-total absence of parameter semantics for a 3-parameter tool with 0% schema coverage 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%, so the description should compensate for all three parameters. It only clarifies `pasta` ('raiz do projeto'); `tarefa` is only implied by the phrase 'relevantes para a tarefa', and `quantos` (default 5) is never explained, leaving the agent to guess its meaning and units.

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 resource and result: the most relevant project excerpts for a task, including file and line positions. It implicitly distinguishes itself from file-listing/search siblings by framing itself as an alternative to 'abrir ou procurar arquivos' and by naming the related 'lembrar' tool. It is missing only an explicit contrast with close siblings like 'ler_relevante' or 'indexar_projeto'.

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 clear timing guidance: 'Use ANTES de abrir ou procurar arquivos num projeto', and explains the benefit versus reading whole folders. There are no explicit exclusion conditions, but the when-to-use case 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?

With no annotations, the description carries the full burden and does well: it discloses that the voice is local (Piper), Brazilian Portuguese, that markdown and code are stripped before speaking, and that input over ~1200 characters is cut. What it omits is operational behavior — whether the call blocks until speech finishes, what happens if there is no audio device, and what the output schema returns.

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

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

Three short sentences: what it does, when to use it, and the input constraints — front-loaded with the action and with no filler or repetition of schema fields.

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, non-destructive audio tool with an output schema already covering the return value, this is nearly complete. The only meaningful gap is the lack of any note on call behavior (blocking vs. fire-and-forget) or failure mode when audio is unavailable.

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

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

Schema coverage is 0%, so the description must compensate, and it does: the single parameter 'texto' is explained as being spoken aloud, with preprocessing (markdown/code removed) and a ~1200-character truncation limit. It still says nothing about how the truncation is signalled or whether the caller should pre-shorten the text.

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 ('fala o texto em voz alta no alto-falante do PC') plus the engine and voice ('voz brasileira local, Piper'), which is enough for an agent to know exactly what the tool does and that it is not a file/audio-generation tool. No sibling overlaps with text-to-speech, so the absence of explicit sibling differentiation is not a gap.

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 an explicit trigger condition: 'Use quando o usuário pedir para ouvir a resposta.' It does not name a when-not case or an alternative, but no plausible alternative exists in the sibling list, so the guidance is effectively complete.

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 two genuinely useful behaviors: a local model auto-writes the message when none is given, and sensitive files (.env, keys) are never committed. However it omits key traits an agent needs: whether staging includes deletions/untracked files, whether the commit is local-only, and any prerequisites or failure modes.

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

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

Two short sentences with no waste; the staging scope is front-loaded and the sensitive-file caveat follows. Slightly terse for a mutation tool, but nothing is padding.

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, but for a commit tool with zero schema coverage the required `pasta` parameter and the exact scope of "todas as mudanças" remain undefined. The definition is thinner than the tool's mutation complexity warrants.

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 supply all parameter meaning. It explains the optional `mensagem` fallback behavior well, but the required `pasta` parameter is never mentioned or defined, leaving the agent to guess whether it is a repo root, a subfolder, or a path filter.

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?

"Adiciona todas as mudanças e commita" states a specific verb (commit) and the staging behavior (adds all changes), which implicitly distinguishes it from siblings like git_push or git_status. It is clear what the tool does, but it never explicitly names the alternatives it is not, leaving sibling differentiation to inference.

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 or when-not-to-use guidance: nothing about running it after git_pull, on which branch, or how it relates to git_push. The agent must infer the whole workflow position of this tool from context alone.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the two side effects (creating a branch and moving HEAD to it), which is real value, but says nothing about failure modes, whether an existing branch name errors out, or what state is left behind.

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 zero filler, and the primary action is front-loaded. It is appropriately terse, though the brevity leans toward under-specification rather than economy.

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

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

An output schema exists, so return values need no explanation, but with no annotations, 0% parameter coverage, and no mention of the two required inputs, the definition is too thin for a mutating git operation. It should at least identify what 'pasta' and 'nome' mean.

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 mentioned in the description. 'nome' (branch name) and 'pasta' (repository folder path) are undocumented in both places, leaving the agent to guess meaning, format, and naming conventions.

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 ('Cria uma branch nova') and adds the resulting state change ('muda para ela'), so an agent knows this is a branch-create-plus-checkout operation. It does not name or contrast itself with any sibling, which keeps it from 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?

There is no when-to-use guidance, no note on prerequisites (clean working tree, existing branch name collisions), and no routing to or away from siblings such as git_pull, git_merge, or git_commit. The agent must infer entirely when this tool is appropriate.

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 load and does disclose a key behavior: on conflict the merge is undone and the affected files are listed, so the agent knows the operation is atomic. It also flags the safety gate on main/master. It leaves unstated whether a successful merge creates a commit or only fast-forwards.

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

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

Two short sentences: the core action plus conflict behavior first, then the confirmation rule. Nothing redundant and nothing buried.

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 mutation/rollback semantics plus the confirmation gate are covered. The remaining gap is the meaning of the required 'pasta' parameter, which an agent must guess.

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 supply meaning, and it does for 'origem' (the branch being merged in) and 'confirmado' (only with user approval, mandatory for main/master). The required 'pasta' parameter is never explained — presumably the repository/working directory — leaving one of three parameters undefined in both description and 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 (merge) and the exact resource/scope: 'origem' merged into the current branch. An agent can separate this from siblings like git_pull or git_commit without opening any 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?

Gives explicit conditional guidance for the optional flag: merging into main/master requires confirmado=true, and it should only be passed with the user's OK. It does not name an alternative tool (e.g. git_pull) or say when not to merge, 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?

With no annotations supplied, the description carries the full burden and does disclose the two behaviors that matter most for a pull: it is fast-forward only and it will not create a merge commit or discard work. It stops short of saying what happens when the branch has diverged (does it fail or abort?) and whether network credentials are needed.

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 short sentence, front-loaded with the action and followed by the critical constraint in parentheses. There is no filler or repetition of the tool name.

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

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

The tool is simple and an output schema exists, so the description mainly needs to cover behavior and the one input. Behavior is handled well, but the total omission of the 'pasta' parameter leaves a real gap for a tool whose only required argument is undocumented.

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, 'pasta', is never mentioned in the description at all. The agent must infer that it is the repository folder path, and nothing is said about whether it accepts absolute/relative paths or what happens with an invalid folder.

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: updates the current branch. It also implicitly distinguishes itself from the git_merge sibling by declaring 'nunca cria merge', so an agent can tell what it does and does not do without opening 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 implied rather than stated: it is the tool to reach for when the current branch needs refreshing from upstream, and the 'no merge' clause hints that git_merge is the alternative when integration is wanted. There is no explicit when-to-use/when-not-to-use routing and no mention of prerequisites such as a configured remote.

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 supplied, the description carries the full burden and does disclose key behavioral traits: force-push is never performed, and main/master pushes are gated behind confirmation. It omits failure modes (non-fast-forward rejection, auth failures) and what happens to the remote on rejection, which keeps 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 short sentences with the core action and the safety constraint front-loaded. 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?

The output schema means return values need not be explained, and the safety behavior is covered. But the required 'pasta' parameter is unexplained in both schema and description, and there are no annotations, leaving the definition short of complete for a mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for 'confirmado' (required for main/master, needs user OK) but never mentions 'pasta', the one required parameter, leaving it fully undocumented.

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

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

States a specific verb and resource ('Envia a branch atual para o GitHub') plus scope qualifiers ('nunca com força', main/master restriction). An agent can tell this apart from git_pull, git_merge, and git_commit without opening any 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?

Gives a conditional rule for pushing to main/master (requires confirmado=true and explicit user approval), which is useful usage guidance. However, it never states when to choose this over siblings like git_commit or git_pull, so the broader when-to-use context 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?

No annotations are provided, so the description carries the full burden. 'Em poucas linhas' usefully signals a deliberately compact, summarized output rather than full porcelain output, but it says nothing about read-only semantics, the need for the target to be a git repository, or what happens when the repo has no remote.

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 short clause listing the three things reported, front-loaded and free of filler. It is arguably too terse rather than padded, so conciseness itself is not the problem.

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, but the tool still requires a 'pasta' argument that neither the schema nor the description characterizes. Given zero annotation coverage and 0% parameter documentation, the definition leaves the agent without enough to invoke it confidently in the right directory.

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 sole required parameter 'pasta' is never mentioned in the description. Whether it is a path relative to the workspace, an absolute path, or a repository root is left entirely undocumented, so the description adds no meaning beyond the bare schema.

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

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

The description names the concrete content produced: branch, relationship with the remote, and changed files, which clearly identifies a git status-style report and distinguishes it from mutating siblings like git_commit, git_pull and git_push. It lacks an explicit verb (e.g. 'mostra/exibe'), but the resource and scope are unambiguous.

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 call this versus the other git siblings (git_pull, git_commit, git_merge, git_push) or versus contexto_projeto. The agent must infer that this is the read-only inspection step before committing or pushing.

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

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

With no annotations, the description carries the full disclosure burden. It usefully reveals incremental behavior (only changed files are reprocessed), which tells the agent the call is cheap to repeat, but says nothing about what determines 'changed', whether removals are handled, cost/locking, or whether the operation is safe to interrupt.

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 compact sentence with the core action front-loaded and the incremental qualifier parenthetically scoped. Nothing is wasted, but the extreme brevity leaves no room for the missing parameter and precondition 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?

An output schema exists, so return values need not be explained, but the sole required parameter is left undefined and no annotations cover safety or side effects. For an index-mutating tool, the definition is too thin for an agent to call it confidently.

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 the single required parameter 'pasta'. An agent cannot tell whether it should be the project root, a relative path, or a subfolder, nor what happens when a narrower folder is supplied. The description 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 and resource — updating the project's search index — which is unique among the siblings (no other tool touches the index). It does not explicitly distinguish itself from adjacent tools like contexto_projeto or ler_relevante, which also read project content, so it falls short of 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?

There is no statement of when to call this versus alternatives, nor any prerequisites. The parenthetical about reprocessing only changed files is a behavioral trait, not guidance about when indexing is needed or when it should be avoided.

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

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

With no annotations at all, the description carries the full disclosure burden and does add one important behavioral rule: dangerous actions are gated behind confirmado=true and user consent. It does not say what happens when confirmado is false for such an action (refusal, error, no-op), nor does it state that the click mutates UI state, what window matching behavior is, or whether a click failure is reported.

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

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

Two short sentences, front-loaded with purpose then the safety rule; nothing is padded. It is under-specified rather than verbose, which is the right failure mode for conciseness but leaves gaps elsewhere.

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

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

An output schema exists, so return values need no explanation. However, for a UI-automation click with destructive potential and zero annotation coverage, the definition leaves the required 'titulo' parameter and the choice among three sibling click tools unaddressed — an agent could invoke it on the wrong surface or with an unset window target.

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 for three bare parameters. It explains 'alvo' (reading number or control name) and 'confirmado' (required for destructive actions), but 'titulo' — presumably the target window identifier and required — is never mentioned, leaving a required parameter entirely 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?

The description names a specific verb and resource ('Clica num controle da janela') and even explains how the target is addressed — by reading number or by control name, with a concrete example ('Salvar'). It does not, however, distinguish this from the sibling click tools navegador_clicar and tela_clicar, which an agent must choose between.

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 real conditional guidance: destructive actions ('enviar, apagar, pagar etc.') require confirmado=true and explicit user approval, which tells the agent when to set that flag. Missing is any guidance on which surface to click on — window vs browser vs screen — or a prerequisite pointing at janela_ler as the source of the reading number it references.

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 usefully discloses the non-destructive insert-at-cursor semantics, but says nothing about required focus/active window, failure modes if the field or window is not found, or any return 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?

Two short, front-loaded sentences with no wasted wording; the destructive-behavior caveat is placed prominently. Only minor awkwardness from the line-broken 'alvo:' clause.

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. Still, for a 3-parameter tool with zero schema coverage and no annotations, the unmentioned required 'titulo' parameter and absent routing guidance leave real 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 coverage is 0%, so the description must compensate. It explains 'alvo' well (number or field name, empty means main field), but the required 'titulo' parameter is never mentioned and 'texto' is only implied by the verb.

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: typing text at the cursor position in a window field, with the non-destructive caveat '(não apaga o que já existe)'. It does not name a sibling to contrast with (janela_clicar, navegador_preencher), so differentiation is left 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?

Usage is implied by 'digita texto na posição do cursor' and the note that existing content is preserved, which hints at when this beats a clear-and-replace approach. However, no explicit when-to-use/when-not or comparison to janela_clicar or navegador_preencher is 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 must carry the full load; it does disclose that this is a read-only enumeration and that partial title matching is accepted. It says nothing about what happens when the title is ambiguous or no window matches, and no permission or side-effect context is given.

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 short sentence, front-loaded with the action and ending with the parenthetical that carries the parameter rule. 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 described, and the tool is simple with one argument. Still, the failure and ambiguity behavior of partial title matching is unaddressed, which matters for an agent driving windows.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that the single titulo argument accepts a partial title. It does not clarify how matching is resolved if several windows share the substring.

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 and resource: lists buttons, fields and menus of a window, with numbered enumeration. That distinguishes it from janelas_listar (which enumerates windows) and from tela_descrever, though the description never names those siblings 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 only implied: the mention of numbering hints that the output feeds into janela_clicar or janela_digitar, but the description never says when to pick this over tela_descrever or navegador_ler, nor any precondition such as the window being open.

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 not state whether the operation is read-only, whether hidden or minimized windows are included, whether it requires an active desktop session, or what errors may occur.

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 unnecessary wording. It states the action and scope directly.

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

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

For a zero-parameter listing tool with an output schema, the description is sufficient to identify the action. However, absent annotations, it should disclose more about read-only behavior, window scope, and environment requirements.

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 meaning for the description to add. The baseline for a parameterless tool is 4.

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, "Lista", and a specific resource, "os títulos das janelas abertas no Windows". It is clear what the tool returns, though it does not explicitly distinguish itself from siblings such as janela_ler or tela_descrever.

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 like janela_ler or tela_descrever. Usage is only implied by the listing purpose, with no exclusions or selection criteria.

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 load and does disclose the key non-obvious behavior: the entry is later injected into `contexto_projeto` when a similar task occurs, which is the effect an agent most needs to know. It omits append-vs-overwrite semantics, deduplication of near-identical entries, and any size or storage limits, so it stops short of full behavioral 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?

Three short sentences, each doing distinct work: purpose and record kinds first, downstream effect second, writing style with an example third. It is front-loaded and free of 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 described, and the persistence effect is covered. However, for a 3-parameter mutation/creation tool with zero schema documentation and no annotations, the unexplained required `pasta` parameter and the absence of duplicate-handling guidance leave real 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. It partially does: `tipo` values are implied ('decisao' default, 'erro'), and `texto` gets content guidance with a concrete example format ('erro: X falhava por Y; resolvido com Z'). The required `pasta` parameter is never explained — no hint whether it is a project path, a folder name, or a memory namespace.

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: 'Guarda uma decisão do projeto ... ou um erro', and names the two record kinds ('decisao', 'erro') that map to the `tipo` parameter. It also distinguishes itself from the read-side sibling by naming `contexto_projeto` as where the stored item resurfaces, so an agent can separate this write tool from retrieval tools without opening either schema.

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

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

Gives clear usage context: record a project decision or an error plus its fix, so the information is available later for similar tasks. It does not state exclusions — for example versus `indexar_projeto`, `ler_relevante`, or general note-taking siblings — but the 'decision or resolved error' framing is specific enough to route most calls correctly.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the single most important trait — that the caller will NOT receive the whole file, but a function map and a task-filtered subset — plus a cost claim. It says nothing about failure modes (file not found, no matching excerpts), truncation limits, or file-type 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?

Two compact sentences, front-loaded with the value proposition and mechanism before the routing instruction. Nothing is filler, though 'pela metade do custo' is a loose quantitative claim that earns its place only as a heuristic.

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 detail is not required, and with only two required params the description's coverage of mechanism and trigger threshold is close to sufficient. Remaining gaps are edge-case behavior and the fact that selection is heuristic, so the output may miss content the agent expects.

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 carry the semantics. It implies both roles well: 'arquivo grande' anchors the file parameter and 'trechos ligados à tarefa' anchors the task parameter as the relevance filter. It adds no guidance on path format (relative/absolute) or on how specifically the task string should be phrased to steer selection.

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 pairs a specific verb (lê/read) with a specific resource (arquivo) and explains the mechanism: a function map with line numbers plus only task-relevant excerpts. It is clearly distinguishable from summarize-style siblings, though it never names a concrete sibling tool for the 'read the whole file' alternative it positions itself against.

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 an explicit trigger condition ('when the file exceeds ~150 lines') and an explicit alternative behavior ('use instead of opening the whole file'). It stops short of stating exclusions, such as when a caller genuinely needs the complete file content or when the file is small enough that the overhead is not worth 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, the description carries the whole burden and does add useful behavior: it discloses the return shape and that credentials persist in the browser profile, which implies persistent state across calls. It omits side effects on existing browser state (does it open a new tab or navigate the current one), what happens on load failure, and any timeout/error 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?

Two short sentences, front-loaded with the action and the return value, then the differentiator versus screenshots. No filler, though the trailing note about saved logins is placed after the usage cue rather than grouped with other behavioral caveats.

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 the description does not need to enumerate return fields and it briefly does anyway; with no annotations the remaining gap is behavioral (tab/window effects, failure modes, URL constraints). For a one-parameter navigation tool it is adequate but leaves real questions open.

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 'url' parameter carries no description in the schema, so the description must compensate — but it says nothing about expected format (scheme required? relative paths allowed?) or whether the URL can point to local files. The only param is required, and its semantics 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?

States a concrete verb and resource ('Abre um site no navegador do agente') and even previews the return payload (page text plus numbered element list), so the agent knows what comes back. It does not explicitly name the sibling it complements, navegador_ler, so the boundary with the follow-up reading tools is only implied.

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 one clear usage cue: prefer this over screenshots because the page arrives as short text. That is genuine when-to-use guidance, but there are no exclusions (e.g. when to use navegador_ler or tela_descrever instead) and no mention of prerequisites such as needing a valid absolute URL or that a browser session must not already be mid-flow.

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 whole behavioral burden, and it does disclose the safety gate: sensitive actions require confirmado=true and explicit user approval. It does not cover failure behavior (element not found, multiple text matches) or whether the tool waits for the page to settle, leaving those unaddressed.

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

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

Two short sentences with zero filler, the target-identification rule front-loaded and the confirmation rule second. The phrasing 'só com o OK do usuário' is slightly compressed but still readable.

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 needn't be described, and the two parameters are fully explained despite 0% schema coverage. Given a crowded field of near-identical click siblings (navegador_clicar, janela_clicar, tela_clicar), the absence of any disambiguation 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 description coverage is 0%, so the description must do all the work, and it does: it defines alvo as either a reading number or literal text with examples, and explains when confirmado must be set to true and under what human condition. Only the default value and false-case behavior are left to the 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 and resource (click an element) and tells the agent how the target is identified: by reading number (e.g. '5') or by visible text (e.g. 'Entrar'). It never distinguishes itself from the sibling click tools (janela_clicar, tela_clicar), so an agent with several click-like options gets no help choosing between 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?

The second sentence gives a concrete conditional rule for confirmado=true covering submit, login, pay and delete buttons, gated on user approval, which is real when-to-use guidance. However, it says nothing about when to use this tool versus the window/screen click siblings, nor does it state the implied prerequisite that the element number comes from a prior navegador_ler call.

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 but only restates the purpose. It does not disclose whether closing destroys session state (cookies, logged-in tabs, form data), whether it errors when no browser is open, or whether it blocks until shutdown completes.

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 short, front-loaded sentence with zero filler or redundant phrasing. Its brevity is appropriate for a no-argument tool, though the terseness is part of why behavioral detail is absent.

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 tool is structurally simple (zero params, output schema present, so return values need not be explained here). However, for a destructive-feeling operation with no annotations, the definition gives no edge-case behavior or safety context, leaving the agent to guess about state loss and error conditions.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The single sentence does not need to explain argument syntax, and no misleading param claims are made.

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?

"Fecha o navegador do agente" states a specific verb (fechar) and resource (o navegador), making the tool's action unambiguous. It is implicitly the counterpart of navegador_abrir, though the description never names or contrasts it with that 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 description contains no when-to-use guidance: it never says whether to close the browser after finishing a task, whether closing is mandatory before restarting, or what alternative exists (e.g., leaving the session open for later navegador_* calls). Usage must be inferred entirely from the tool 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 behavioral burden, and it does disclose the key trait that the output includes numbered element handles ([1], [2]...) suitable for later interaction. It does not state that the operation is side-effect-free, whether reading is required after each action, or any limits on how much page text is returned.

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

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

A single compact sentence with the resource and the returned fields front-loaded, no filler. The word 'de novo' is slightly ambiguous without a stated trigger, which is the only inefficiency.

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

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

For a zero-parameter read tool with an output schema, the definition is nearly complete: it names the target and the returned content. The one gap is the interplay with the numbered elements, i.e. that those numbers are the handles used by navegador_clicar, which would make the tool self-explanatory in context.

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 nothing for the description to disambiguate; baseline applies. The sentence spends its words on output shape instead, which is reasonable for a no-arg tool.

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 ('Lê ... a página atual') plus the exact payload returned: título, texto and numbered elements ([1], [2]...). This clearly separates it from page-mutating siblings like navegador_clicar or navegador_abrir, though it never names the closest alternative, janela_ler.

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?

'Lê de novo' hints that this is a re-read of the already-open page, implying it follows a navigation or click action. However, no explicit when-to-use condition, no exclusion, and no mention of when janela_ler would be the right choice instead.

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 supplied, the description usefully discloses text-based list selection and a consent-gated safeguard for sensitive password input. It does not clarify whether existing content is replaced, whether filling triggers submission, or how invalid targets are handled.

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 compact and front-loads the core operation, then adds list behavior and the password safeguard. Every sentence supplies distinct, actionable information without 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 simple three-parameter tool with an output schema, this covers enough targeting, value-selection, and safety behavior to support most invocations. It would be more complete with the source of numeric field identifiers, browser-page prerequisites, and a brief distinction from sibling input 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?

Despite 0% schema description coverage, the text explains that the target may be a number or label, that list values are matched by option text, and what confirmado controls. The meaning of numeric targets and any expectations for valor in ordinary fields remain somewhat implicit.

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

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

“Preenche um campo” states a clear action and resource, while “Em listas, escolhe a opção pelo texto” clarifies select-list behavior. It does not explicitly distinguish this browser tool from siblings such as navegador_clicar, navegador_tecla, or janela_digitar.

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 concrete usage contexts for ordinary fields and lists, plus an explicit restriction for password fields: use confirmado=true only with the user's approval. It lacks guidance on prerequisites or when to prefer a sibling tool, but the conditional password rule is useful operational 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 at all, the description carries the full behavioral burden and fails: it never says that the key goes to the currently focused element, that keys like Enter/Escape can submit forms or navigate away, or whether the action is reversible. Beyond restating the tool name it discloses nothing consequential.

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 short sentence, front-loaded with the action and immediately followed by examples. Nothing is wasted and no restructuring would help.

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 an interactive browser tool with zero annotation coverage and an undocumented confirmation flag, the definition is too thin to call it reliably — the agent cannot know whether a confirmation step is expected or what side effects to anticipate.

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% for two parameters. The description supplies useful key-name syntax for the required 'tecla' field, but the second parameter 'confirmado' (a confirmation boolean with default false) is left entirely unexplained in both schema and description, which is a meaningful gap for an action that can mutate page state.

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 target ('Aperta uma tecla na página') and gives concrete key examples ('Enter', 'Tab', 'Escape', 'PageDown'), so the agent can tell it apart from navegador_clicar or navegador_preencher. It never explicitly names those siblings as alternatives, so it stops short of full differentiation.

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 press a key versus clicking or typing, no mention of focus or where the keypress lands, and no exclusions. The agent must infer that a page element needs focus for this to be meaningful.

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 declares the tool is strictly read-only ("nunca move, renomeia ou apaga nada"), discloses that it writes report files to disk, and warns about runtime on multi-GB folders along with the mitigation (hash comparison only reads whole files when size and a chunk match). It stops short of stating whether existing reports are overwritten or what credentials/OmniRoute access are required.

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

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

Two short paragraphs, front-loaded with what it does and what it produces, then the safety/performance caveats. The duplicate-hashing detail is technical but earns its place by justifying the slow-runtime warning; nothing is padded.

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 description still adds the artifact formats and destination directory. Combined with the read-only guarantee and performance caveat, an agent has enough to call it correctly; only the "pasta" path format remains unspecified.

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 required parameter "pasta", and the description adds nothing about expected format, absolute vs relative path, whether a trailing slash matters, or whether the folder must exist. The one parameter the agent must supply is left entirely to guesswork.

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 ("Levanta uma pasta") plus the exact artifacts produced (inventário, duplicados por hash, sugestão de estrutura) and where they are written (dados/organizador/). No sibling tool does folder analysis, so an agent can route here unambiguously without opening 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 implied by the described outcome — use it when you want an inventory/duplicate analysis of a folder — but there is no explicit when-to-use, when-not, or named alternative among the siblings. The only guidance is the implicit inference from the read-only nature of the operation.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the Maestro turns a worker on and off around the call, the response is short, and the answer comes from a small local model whose facts must be verified. The sentinel return value 'PRECISA DO CLAUDE' is also a genuine behavioral disclosure that the agent must handle. It stops short of stating latency, cost, or failure modes, which would round out a dispatcher that can silently route work elsewhere.

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 routing purpose is front-loaded and the text is short, but the parenthetical '(pasta: projeto ...)' is jammed into the running prose in a way that reads like a stray parameter note rather than a structured line. The telegraphic, run-on phrasing costs a little parsing effort without adding 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?

An output schema exists, so return-shape explanation is not required, and the description still flags the one return value that changes agent behavior ('PRECISA DO CLAUDE'). For a two-parameter orchestrator this is close to complete; what is absent is any notion of the tool's cost or latency, which matters for something the description tells the agent to call on every turn.

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 only partly does: 'Pedido em português' tells the agent the request must be written in Portuguese, and 'pasta: projeto (opcional, se o pedido não citar o nome)' explains that the folder is optional and only needed when the request does not name the project. Neither parameter gets format examples, naming conventions, or an explanation of what happens if the folder is omitted and unresolvable.

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 routing behavior: the local Maestro picks which worker (Revisor, testes, git, Memória, or the Cérebro for simple questions) handles the request and returns a short answer. That is a real verb-plus-mechanism, not a restatement of the name. The gap is sibling differentiation: it never contrasts itself with perguntar_local or segunda_opiniao, which overlap heavily with the 'Cérebro para perguntas simples' path.

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

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

It gives an unusually explicit trigger: 'Chame em toda conversa, antes de trabalhar' (call in every conversation, before working), plus a fallback rule when the sentinel 'PRECISA DO CLAUDE' comes back. What is missing is when NOT to use it, i.e. whether perguntar_local or segunda_opiniao should be preferred for direct local queries.

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 the meaningful runtime fact that execution happens on the user's local machine at zero token cost. It omits what happens if the local model is unavailable, expected latency, and whether output quality differs from Claude — all relevant for an agent choosing this over a cloud call.

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

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

Three short lines, front-loaded with the core action and the cost-saving rationale, then use cases, then parameter modes. No filler; it could be marginally tighter by folding the papel note into a single clause.

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 correctly omitted, and both parameters are covered at a basic level. What is missing for a delegation tool is failure/fallback behavior when the local model is down or slow, which an agent needs to decide whether to retry or escalate to a sibling.

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 schema defines no enum for 'papel', so the description is doing real work by explaining the two modes: 'codigo' (default) for code and 'cerebro' for general reasoning. 'pergunta' is left implicit, but its meaning is self-evident from the name.

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 asks the local model running on the user's own PC, with the explicit qualifier that it is free and consumes no Claude tokens. This differentiates it in spirit from siblings such as segunda_opiniao and pedir_ao_agente, though none of those siblings is named directly.

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?

'Bom para: explicar um erro, rascunhar texto, gerar código simples' gives concrete positive use cases, which is more than most definitions offer. However, it never says when NOT to use it or when to prefer the cloud/agent siblings (segunda_opiniao, pedir_ao_agente, resumir_texto), so routing remains inferential.

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 present, the description carries the full burden and does well: it discloses the destructive side effect (the app is closed), the concrete cost ('A conversa atual é interrompida por uns 10 s'), and the confirmation requirement. It stops short of saying whether unsaved work beyond the conversation is affected.

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

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

Two short sentences: the action and its purpose come first, then the cost and the confirmation gate. No filler, nothing redundant with the 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?

An output schema exists, so return values need no explanation, and the description covers action, rationale, side effect, and the confirmation gate. Minor gap: it does not say what the caller should do if the restart fails or whether a success/failure result must be surfaced to the user.

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 'confirmado' boolean, so the description must compensate, and it does: it explains that confirmado=true is mandatory and that it must reflect actual user approval, not agent initiative. The type/default are left to the schema, which is acceptable for one flag.

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 ('Fecha e reabre o Claude Desktop') and even supplies the reason ('para carregar ferramentas novas do agente'). No sibling tool does app restart, so the boundary is unambiguous.

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 states the triggering situation (loading new agent tools) and a hard precondition ('só com o OK do usuário'), which functions as a when-not rule. It does not enumerate alternative approaches for refreshing tools, but for a single-purpose restart tool the guidance is clear.

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; it does disclose that the figure is an estimate rather than an exact measurement, which is meaningful behavioral context. However, it says nothing about the data source, the time window covered, whether it is strictly read-only, or whether the local agent must be running. For a zero-parameter report tool the risk is low, so a 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?

A single short sentence that leads with the quantity being reported and immediately qualifies it as an estimate and states the breakdown dimension. No filler, no repetition of the tool name.

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

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

The tool is simple (no parameters) and an output schema exists, so return-value detail need not be described. What is missing is the scope of the report — time range, whether it covers one session or all history, and how 'savings' is defined — which an agent would likely want before invoking 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?

The tool takes zero parameters and the schema description coverage is 100%, so there is no parameter surface for the description to explain. Baseline 4 applies; the mention of 'por tipo de tarefa' does hint at the shape of the aggregation, which adds slight value.

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 concrete metric (tokens saved by the local agent) and its grouping (per task type), with the caveat that it is an estimate. The verb is implicit — it is a report/read tool rather than an action — but an agent can still tell what it returns. There is no explicit differentiation from siblings, though none of the listed siblings appear to cover cost/economy reporting.

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 no indication of when to call this versus alternatives, or under what conditions the report is meaningful (e.g. after a session, over what period). Usage is only inferred from the noun phrase itself. No exclusions or prerequisites are 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. It does disclose the key behavioral trait that the file contents are not returned in full, only a condensed summary, but it omits limits such as maximum file size, permission/path constraints, and what happens on unreadable or binary files.

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

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

Two short sentences with the core capability and usage trigger front-loaded; nothing is wasted. The trailing "foco: o que procurar no arquivo" is a fragment rather than a sentence, which slightly hurts polish.

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 needn't be explained. However, with no annotations and zero schema description coverage on a two-parameter tool that touches the user's local filesystem, the definition should say more about path expectations and size/error limits to be fully callable with confidence.

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. It adds real meaning for "foco" (what to look for in the file) and implies "caminho" is a local filesystem path, but leaves format details (absolute vs relative path, encoding, whether foco is required in practice) unstated.

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 reads a large file on the user's local machine and returns only a summary, with concrete examples (log, CSV, code). This clearly distinguishes it from browser/window readers and from resumir_texto, 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?

"Use before opening long files entirely" gives a clear trigger condition tied to file length, which is the deciding factor for choosing this tool. It stops short of naming alternatives (resumir_texto, ler_relevante) or stating when-not to use it, so no explicit routing is provided.

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

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

With no annotations at all, the description carries the full disclosure burden; it does add real value by stating processing is local ('localmente') and that only the summary is injected into context, which is the key behavioral trait for an agent managing its window. It does not say whether the submitted text is stored or logged anywhere, nor confirm that the operation has no side effects on the source.

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

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

Three short lines with the purpose front-loaded, followed by the usage preference and a parameter hint — no filler or repetition. The trailing 'foco:' fragment is terse but readable; slightly cleaner formatting would make the parameter note stand out more.

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 tool is low-complexity with two parameters. The description covers purpose, selection rationale, execution locality, and parameter intent; only edge behavior (empty 'foco', input size limits) is 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 description coverage is 0% (properties have only titles 'Texto' and 'Foco'), so the description must compensate, and it largely does: 'texto' is characterized by example content types (log, command output, diff) and 'foco' is explained with a concrete sample value ('quais testes falharam e por quê'). It omits what happens when 'foco' is left empty (the default ""), which is the remaining semantic 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 and resource: 'Resume um texto longo (log, saída de comando, diff) em poucas linhas, localmente' — verb, input type, output shape, and execution locality are all named. It does not explicitly contrast with the sibling 'resumir_arquivo', but the enumerated input types (log, command output, diff) make the text-in vs. file-in distinction inferable.

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

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

Gives explicit when-to-use guidance plus a rationale: 'Prefira esta ferramenta a ler saídas grandes inteiras: só o resumo entra no contexto', which tells the agent this tool should replace raw reads for context economy. No explicit when-not-to-use or named-alternative routing (e.g., toward resumir_arquivo) is provided.

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 only problems are returned, with file and line, and warns that opiniao output comes from a local model and should be verified before acting. It omits whether the tool is read-only or how long a run takes, but the trust caveat on opiniao is a 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?

Front-loads the scope, then output behavior, then usage, then parameter notes; each sentence earns its place. The parenthetical enumeration of suspicious patterns is dense but informative rather than 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?

An output schema exists, so the brief return-value note ('only problems, with file and line') is a bonus rather than a necessity. Combined with the scope list, usage trigger, and parameter toggles, an agent has enough to call it correctly; only read-only/permission behavior is 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 description coverage is 0%, so the description must compensate, and it explains two of three parameters: testes=False skips tests, and opiniao=True asks the local code model to read the diff. The required pasta parameter's meaning is left implicit from the name, which is a minor 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?

Opens with a specific verb-plus-scope: a local review that runs lint, type checks, tests, and scans changes for secrets, conflict markers, leftover debug code, and large files. That enumeration makes it clearly distinct from narrow siblings like rodar_testes (testing only) and segunda_opiniao (model opinion only), since this tool composes all of 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?

Gives an explicit trigger: use it before reviewing code or declaring a task done. It does not name alternatives explicitly (e.g. when to call rodar_testes alone instead), but the timing guidance is clear and actionable.

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

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

With no annotations at all, the description carries the full behavioral burden. It usefully discloses the framework auto-detection and the aggressive output summarization, but says nothing about execution semantics: how long it may run, whether it can hang or time out, whether a failing suite is returned as data or raised as an error, and what happens if no test setup exists. These are the traits that matter most for a tool that executes code on the user's machine.

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

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

Three short lines, front-loaded with what the tool does and what it returns, then the usage rule, then the parameter note. Nothing is padded, and the only mild repetition ("Roda os testes do projeto" echoed by the usage line) is functional restatement of intent.

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 the description needn't enumerate return values, and it explicitly does not. For a one-parameter execution tool the definition is nearly sufficient; the remaining gap is failure/timeout behavior and required project preconditions, which the agent cannot infer from the schema or the absence of annotations.

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 schema only says the string parameter is titled "Pasta", so the description must compensate. It does, clarifying that the value is the project root directory on the user's own PC, which tells the agent this is a local filesystem path rather than a container or remote path — meaningful context the schema lacks.

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: runs the project's tests, explicitly detecting pytest or npm test, and returns only counts, failures and cause. The scope of the result is named up front, so an agent knows this is a condensed test runner rather than a generic shell executor. No sibling tool in the list runs tests, so differentiation is trivially satisfied.

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

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

"Use no lugar de rodar os testes no terminal e ler a saída inteira" gives an explicit alternative (terminal) and the condition that selects this tool (you want the summarized result, not raw output). It stops short of stating when not to use it, e.g. when no test framework is configured or when the user wants the full log.

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 burden and does reasonably well: it discloses that the model is local and free, that it does not consume Claude tokens, and critically that the answer comes from a small model and should be verified before acting. That reliability caveat is genuinely useful and not inferable from structured fields. It still omits latency expectations and whether the call has any side effects.

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 and the token-saving rationale are front-loaded, and the parameter explanations follow in a compact block. The 'ao estilo do zen-mcp-server' reference and some parenthetical asides are expendable, but the text is short and no sentence 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?

An output schema exists, so return values need not be described, and the description goes further by warning about output reliability. For a three-parameter advisory tool this covers what an agent needs to invoke it correctly. The main missing piece is sibling differentiation against 'perguntar_local' and the other summarize/ask 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?

Schema description coverage is 0% and the schema declares no enum for 'papel', so the description is doing essential work by enumerating 'codigo' (default, technical review), 'cerebro' (general reasoning), and 'visao' (when the context describes something visual). It also explains 'contexto' as optional relevant code or text. 'pergunta' is left to its self-evident name, which is acceptable.

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 concrete verb+resource: it asks a local model for a second opinion on a decision, code snippet, or plan, and explicitly frames it as a free alternative that avoids Claude token spend. That is a clear, specific purpose an agent can act on. It stops short of a 5 because it never contrasts itself with the nearby sibling 'perguntar_local', which an agent could plausibly confuse with this 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 states the triggering situation precisely: use to check a decision, code fragment, or plan before proceeding, without spending Claude tokens. The 'papel' values also route sub-use-cases (technical review vs. general reasoning vs. visual context). It lacks explicit when-not-to-use or a named alternative among the 38 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?

No annotations are supplied, so the description carries the full behavioral burden. "Mostra" implies a read-only inspection with no side effects, and it discloses the categories of data returned, but it says nothing about cost, latency, failure behavior (e.g., what happens when Ollama is down), or whether any permissions are needed.

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 short sentence with no filler, and the primary signal (is Ollama up) is placed first, followed by the secondary details. Every clause corresponds to something the tool actually reports.

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 re-explained, and the description already previews the main outputs. For a zero-parameter diagnostic tool this is close to sufficient; the only gap is the absence of any note on when to prefer it over simply proceeding with a model call.

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 meaning to convey; the baseline for a parameterless schema is 4. The description correctly avoids inventing arguments that do not exist.

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?

"Mostra se o Ollama está no ar, os modelos instalados e quanto do PC está em uso" names a specific verb (Mostra) and three concrete pieces of information returned: Ollama availability, installed models, and machine resource usage. It is clearly a status/health-check tool, distinguishable from the browser, git, and window siblings by domain. It stops short of explicitly framing itself as a read-only diagnostic, which keeps it at 4.

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 statement, no prerequisites, and no named alternative among the many siblings. Usage is only implied by the content: an agent can infer it should call this to verify the local model runtime is available before invoking model-dependent tools, but the description never says so.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses that the search spans every window and the taskbar, but says nothing about what happens on no-match or on multiple matches, whether it needs an unlocked GUI session, or what side effects result from an accidental click on a similarly named control.

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 scope stated first and the matching-performance tip second; nothing is padded. The trailing example is slightly noisy but earns its place by showing the real taskbar caption format.

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

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

An output schema exists, so return values need no explanation, but for a desktop-automation click tool the definition omits failure modes, ambiguity handling, and half of the parameter surface ("confirmado"). An agent cannot tell what happens when several windows expose the same button label.

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 adds meaning for "alvo" via the exact-name preference, but "confirmado" is never mentioned at all — its name suggests a confirmation gate whose effect on execution is 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 concrete verb and resource ("Clica em qualquer botão visível pelo nome") plus the search scope ("procurando em todas as janelas e na barra de tarefas"), with a concrete example. It implicitly distinguishes itself from the window- and browser-scoped siblings (janela_clicar, navegador_clicar) by claiming a whole-desktop search, but never names 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?

The all-windows scope implies when to reach for this over a window-specific click, and "Nome exato é bem mais rápido" hints at an alternative matching strategy, but the agent must infer both. No sibling is named and no exclusion (e.g. "prefira janela_clicar quando sabe a janela") is 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 behavioral burden, and it does disclose one meaningful trait: the image never reaches the caller, only a textual description produced by a local vision model. It omits other operationally relevant facts such as capture scope (whole desktop vs. focused window), latency, or whether an active/visible screen is required.

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

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

Two short statements, front-loaded with the core action and followed by the parameter meaning. The line break and quoted parameter line are slightly awkward but nothing is wasted; it could be tightened into a single sentence 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?

An output schema exists, so return-value explanation is rightly omitted, and the single-parameter surface is small. What remains underspecified is the capture target — the family of siblings suggests window-level and browser-level reading tools exist, so knowing whether this captures the whole screen or a focused window matters 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, and it does: it explains that "pergunta" is what the agent wants to know about the screen and supplies a concrete example. It does not state that the parameter is optional with an empty default or describe behavior when it is omitted.

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 pair: takes a screenshot and has a local vision model describe it as text. The parenthetical "nenhuma imagem para você" usefully clarifies that the caller receives a description, not pixels. It does not, however, contrast itself with visual-reading siblings such as janela_ler or navegador_ler, so an agent must infer the distinction.

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 "pergunta" line implies the usage pattern — ask a targeted question about the screen — and the example ('apareceu alguma mensagem de erro?') reinforces it. There is no explicit when-to-use versus when-not guidance and no mention of alternatives like janela_ler for reading a specific window's text.

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