Manage Static Route

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

Annotations already include destructiveHint=true and idempotentHint=true. The description adds value by specifying that idempotency checks apply only to add operations and that dry-run mode is supported. However, it fails to mention the confirmationToken parameter's critical role for destructive actions or what happens on idempotent add (e.g., no change). The description partially complements annotations but misses key behavioral details.

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 consists of exactly two sentences: the first clearly states the core purpose, and the second highlights two important features (idempotency checks and dry-run). There is no redundant or extraneous information. Every word serves a purpose, making it highly efficient.

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?

Despite detailed parameter schema, the description lacks essential context for a tool with 10 parameters and no output schema. It does not explain the confirmationToken parameter's purpose, the return value, error conditions, or the fact that remove operations are destructive. While the schema covers individual parameters, the tool's overall behavior and workflow remain underdocumented.

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 100%, so all parameters are already documented. The description does not add any new meaning beyond what the schema provides. It mentions dry-run and idempotency, which relate to parameters (dryRun and idempotent add behavior), but these are not directly tied to specific parameter usage. With full schema coverage, a baseline score of 3 is appropriate.

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 states the tool's purpose: 'Add or remove a static route on a MikroTik router.' It specifies the verb (add/remove) and resource (static route), and distinguishes from sibling tools like list_routes or manage_routing_rule by explicitly targeting static route management.

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. It does not mention that list_routes is for viewing existing routes, nor does it explain scenarios where manage_routing_rule or manage_routing_table might be more appropriate. There is no explicit 'when-to-use' or 'when-not-to-use' advice.

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