check_uci_approvalCheck UCI approval status for wheels matching a company and/or model (partial matches). At least one of company or model is required. Returns up to 20 matching wheels, each with its stored UCI Approved value (Yes / No); a blank value means not yet checked, not "not approved".
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (partial match) | |
| company | No | Manufacturer name (partial match) |
Changes observed during successful MCP inspections.
Does 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 explains the return shape (up to 20 wheels), the stored values (Yes/No), and crucially disambiguates blank values as 'not yet checked' rather than 'not approved'. It does not mention rate limits or auth, but for a simple read-style lookup the key behaviors are covered.
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 no wasted words. The core purpose and matching behavior are front-loaded, followed by the input requirement and the essential return-value nuance. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple optional-looking string parameters, no output schema, and no annotations. The description sufficiently covers what the agent needs: required inputs, match behavior, result cap, returned values, and the interpretation of blank results. Nothing critical is missing 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 100%, so the schema already documents both parameters. The description adds meaning beyond the schema by clarifying that the parameters can be used alone or together, that at least one is required, and that matching is partial. This is genuinely useful semantic context rather than repetition.
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 ('Check') and a specific resource ('UCI approval status for wheels'), and distinguishes itself from siblings such as compare_wheels, get_wheel_price, and search_wheels by focusing on UCI approval. The matching criteria and partial-match behavior are immediately clear.
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: at least one of company or model is required, matching is partial, and results are capped at 20. It does not explicitly name alternatives or state when not to use this tool, but the intended use case is unambiguous for an agent choosing between wheel-related lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.