delete_d_company_agent_discoverysettings_mapping_id

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

With no annotations provided, the description must bear the full burden of behavioral disclosure. It indicates a mutation through 'Delete', but it does not disclose consequences such as irreversibility, authorization requirements, or side effects on related entities. It also mentions 'filters' and 'pagination' in query, which is an unusual behavior for a delete-by-id endpoint, but offers no explanation of how that behaves.

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 a single compact sentence that conveys the operation, endpoint, and a rough parameter-to-request component mapping. It is front-loaded with the purpose. The phrase 'Calls' is a bit awkward and the sentence could be clearer, but it is concise and doesn't waste words.

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?

Given the 0% schema coverage and no annotations, the description leaves the agent with several unknowns: it does not say the ID is required, which filters/pagination keys to use, whether body must be sent, or any auth/prerequisite expectations. The presence of an output schema helps but does not compensate for the gap in request semantics. A delete-by-ID tool with this little handling is insufficient.

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 0%, so the description is the only guidance, and it does add meaning by mapping path_params to route IDs, query to filters/pagination, and headers to required request headers. That is a non-trivial contribution over the empty schema. However, it does not name the actual parameters or indicate whether body is relevant, leaving an agent with ambiguous instructions.

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 states a clear delete action on a specific resource ('agent_discoverysettings_mapping') and even includes the exact HTTP endpoint. It is distinguishable from the post/patch/get variants for the same resource, so an agent can tell this is the deletion operation. A slightly cleaner explanation of what a 'discoverysettings mapping' is would make it a 5.

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 gives no explicit guidance on when to use this tool versus its siblings (post, patch, get). It does not state 'use this to remove an existing mapping' or mention prerequisites. The only usage hints are the preceding 'Delete' and the parameter placement instructions, which are more about invocation mechanics than decision-making.

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