Evaluate local state to return a typed yes/no, choice, or score outcome with an auto, review, or stop action. Use presets for command, subagent, diff, file, commit, or package scenarios.
Typed local decision over state. Presets: comando, subagente, diff, ficheiro, commit, pacote. Returns yesno/choice/score plus action auto|review|stop. Do not invent probabilities in text.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| preset | No | ||
| questions | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that the decision is 'local', specifies the return contract (yesno/choice/score plus action auto|review|stop), and adds a meaningful constraint: 'Do not invent probabilities in text.' It omits details like side effects or failure modes, but the local qualifier and output contract give useful transparency.
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 definition is compact and front-loaded: purpose, presets, output contract, and a constraint in four short clauses. There is no filler or redundancy. The closing probability instruction earns its place because it is a rule for correct use.
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 moderately complex (union-typed state, nested questions object, preset enum) and has no output schema, no parameter descriptions, and no sibling context. The description leaves key invocation details implicit, such as the semantics of state, how questions are structured, and what the action values mean. It is minimally usable but not complete enough for confident call construction.
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 only repeats the preset values that already exist in the enum. It does not define the required 'state' parameter, explain what 'questions' means, or clarify how presets affect behavior. The preset names and action values add a little context, but not enough to compensate for the undocumented parameters.
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 resource ('state') and the output shape (yesno/choice/score plus action), and lists presets, so it is more than a tautology. However, it lacks a concrete verb: 'decision' essentially restates the tool name, and what a 'typed local decision' actually does is left fuzzy without sibling tools for contrast.
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 about when to use this tool, when to prefer a preset versus questions, or what conditions should route to it. Even with no sibling tools, the description could describe intended scenarios but does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.