rodar_testes

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.