delete_media_providers_by_provider

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

Annotations already communicate that this is destructive (destructiveHint: true) and not read-only. The description adds no behavioral context beyond the bare word 'Delete' and the endpoint; it does not explain irreversibility, side effects on dependent objects, permissions, or what destruction entails. With annotations present, the bar is lower, but the description still adds nothing beyond them.

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 compact and front-loaded with the core action. The Args section is slightly redundant with the input schema, and the endpoint line largely mirrors the tool name, but there is no filler or wasted prose. It is appropriately sized for a one-parameter delete operation.

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 one-parameter delete operation with strong annotations and no stated output schema content, the description covers the essential call shape. It falls short on context such as what happens after deletion, whether deletion is permanent, or how this relates to provider management workflows. It is adequate but not richly complete.

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 clarify the parameter, and it does state that provider is 'The ID of the media provider to delete.' This adds meaning beyond the schema's bare type and title. However, it provides no format, examples, or further constraints, so it is only minimally compensatory.

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 uses a specific verb and object: 'Delete a media provider.' This clearly distinguishes it from sibling tools like delete_media_subscriptions_by_subscription_id and delete_media_grabbers_devices_by_device_id. The endpoint line reinforces the exact resource and HTTP method.

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 usage is implied by the verb and resource—use this when you need to delete a media provider—but there is no explicit statement about when to use it versus related tools like create_media_providers or list_media_providers. It gives no exclusions or alternatives, but for a simple delete operation the purpose largely carries the usage context.

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