delete_script

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

With no annotations, the description carries the full disclosure burden. It helpfully clarifies that the deletion is local to the repo (remote removal requires a separate sync) and that archiving is optional before deletion, but says nothing about reversibility of the archive, permissions, or failure modes.

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 short sentences, front-loaded with the core action and followed by the workflow context. No filler, though the second sentence is a bit loosely tied to the tool itself rather than to calling it.

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 two-parameter mutation tool with no annotations but an existing output schema, the description covers the essential local-vs-remote behavior and the follow-up sync step. It is adequate but thin on safety and parameter detail, leaving gaps that neither the schema nor annotations fill.

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%, so the description must compensate. It does explain the 'archive' parameter ('optionally archiving it first', consistent with default true) and implies file_name points at a script in scripts/, but gives no format guidance (extension, relative path) beyond that.

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 ('Delete a Lua script') and scopes it to 'the MCP repo's scripts/ folder', which distinguishes it from the project/directory delete variants by location. It stops short of naming those siblings, so the differentiation relies on the agent reading the folder scope.

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 'Context' sentence gives a clear usage condition: perform a local delete, then sync the project/directory if the remote editor must also drop it. This tells the agent when this tool is the right entry point and what follow-up action is required, though it never names the alternative delete tools or states when not to use this one.

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