Identify C# anti-patterns in UdonSharp before writing code to prevent common errors and ensure valid implementations.
WHEN: BEFORE using unfamiliar C# patterns or when validate_code fails with a common mistake. HOW: check anti-patterns to avoid; prefer documented alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Anti-pattern to check BEFORE using unfamiliar C# patterns in UdonSharp |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says to 'check' anti-patterns but does not state what the tool returns, whether it is a read-only search, or how results are structured. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is roughly 30 words and every phrase adds actionable guidance. The WHEN/HOW structure front-loads the most important usage information and avoids filler or repetition.
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 two-parameter search tool, the description gives enough context to know when to call it, but it omits what a successful result looks like and how to interpret the returned anti-patterns. With no output schema and no annotations, this leaves the agent partly guessing about return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the query parameter as an 'Anti-pattern to check BEFORE using unfamiliar C# patterns in UdonSharp,' and the description reinforces that context. However, the description adds nothing about the limit parameter, and schema coverage is only 50%, so parameter meaning is only partially expanded.
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 clearly identifies the resource ('anti-patterns') and the action ('check'), and adds concrete trigger context: 'BEFORE using unfamiliar C# patterns' and 'when validate_code fails with a common mistake'. It is distinguishable from siblings like search_documentation by focusing on anti-pattern avoidance, though it never explicitly says it searches a repository of anti-patterns.
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 WHEN clause explicitly names two situations to use this tool: before using unfamiliar C# patterns and when validate_code fails with a common mistake. The HOW clause adds that the agent should 'prefer documented alternatives,' which helps route away from anti-patterns afterward, though it does not explicitly compare against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.