edubase_delete_integration_permission

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

The annotations declare destructiveHint=true and idempotentHint=true, which already indicate that the tool is destructive but safe to retry. The description does not contradict these annotations. However, beyond the annotations, the description adds no additional behavioral context—such as whether removing permissions cascades, requires special authorization, or affects related resources. Since annotations already carry the basic safety profile, the description's lack of extra context earns a mid-range score.

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 concise sentence that front-loads the core action. At 7 words, it wastes no space. While effective, it omits any contextual depth that might be useful, but for clarity and brevity, it scores well.

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 tool has 3 required parameters, a clean schema, and an output schema (though not shown here), the bare-bones description is minimally acceptable for a simple CRUD operation. However, it lacks any guidance on preconditions (e.g., does the integration exist? must the user have certain roles?), which reduces completeness. The presence of siblings like edubase_get_integration_permission and edubase_post_integration_permission further suggests that context about the permission lifecycle would be helpful.

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?

The input schema has 100% coverage, with descriptions for all three required parameters ('user', 'permission', 'integration'). The description itself does not add meaning beyond what the schema provides—it doesn't clarify format constraints, relationships between parameters, or expected values. Baseline 3 is appropriate given full schema coverage, as the agent can rely on the schema for parameter understanding.

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 verb ('Remove') and resource ('user permission from an integration'), making the tool's purpose immediately understandable. However, it doesn't explicitly distinguish it from sibling tools like edubase_delete_integration (which deletes the entire integration) or edubase_post_integration_permission (which adds permissions), so it misses some differentiation.

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. Given that there are multiple sibling tools for managing integrations and permissions (e.g., edubase_post_integration_permission, edubase_delete_integration), explicit usage context is absent. The agent must infer that this tool is for removing specific permission assignments, but no when-to-use or when-not-to-use information is given.

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