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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no further behavioral context (e.g., effect of removing non-existent users, permission requirements). It is not contradictory but adds minimal value beyond annotations.

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?

Single, front-loaded sentence with no unnecessary words. Every word earns its place.

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?

The description is adequate for a simple parameterized delete operation but lacks information about return values (no output schema). Given the minimal description and no output schema, more detail would improve completeness.

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 100% with clear parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides. Baseline 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 removes users from a class, using a specific verb and resource. It distinguishes from siblings like edubase_delete_class_permission (which removes permissions) and edubase_post_class_members (which adds users).

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?

No guidance on when to use this tool vs alternatives (e.g., edubase_delete_user_classes for removing a user from all classes). The description only states the action without providing context for selection.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description 'Remove' is consistent but adds no additional behavioral context, such as whether removal is permanent, permissions required, or effect on non-existent permissions.

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 sentence, which is concise. It is front-loaded with the action, but lacks some important usage details that would make it more helpful.

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?

The tool has 3 required parameters and an output schema, but the description does not explain the return value, error conditions, or prerequisites for using this tool. Given the existing annotations and schema, the description is minimally adequate but leaves gaps.

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?

All three parameters are fully described in the schema (100% coverage). The description does not add any additional meaning or constraints beyond what the schema already provides.

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 the specific verb 'Remove' and identifies the resource 'user permission from a class'. It clearly distinguishes from siblings like edubase_post_class_permission (add) and edubase_get_class_permission (list).

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 (e.g., other delete permission tools, or when to use post vs delete). No prerequisites or context for usage are given.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds minimal context beyond "remove a tag attachment", which is consistent but does not disclose additional behavioral details like what happens if the tag is not attached or whether the operation is reversible.

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, front-loaded sentence of only 6 words with no filler. Every word earns its place for this simple tool.

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 simple tool with 2 parameters, existing annotations, and an output schema, the description is sufficiently complete. It clearly states the action and resource, though it could optionally mention idempotency (already covered by annotations).

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 100% with both parameters having descriptions. The tool description does not add any additional meaning beyond what the schema provides, so the baseline 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 uses a specific verb "remove" and resource "tag attachment from a class", clearly distinguishing from siblings like edubase_delete_course_tag or edubase_delete_class_members.

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?

No guidance is provided on when to use this tool versus alternatives. There are many sibling tag deletion tools (e.g., for courses, events, exams) and the description does not specify the context that differentiates them.

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

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

Annotations already set destructiveHint=true (confirms mutation), readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds nothing beyond "Remove a user permission from a course." The annotation about idempotentHint=true is somewhat surprising for a delete operation, but the description does not clarify or contradict it. No additional behavioral details (e.g., what happens if permission doesn't exist, whether it returns an error or silently succeeds) are provided. This is adequate given annotation coverage but not exemplary.

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 sentence with zero wasted words. It is extremely concise while still conveying the core purpose. It is appropriately sized for a delete operation with well-documented schema parameters.

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 (all documented in schema), an output schema (which reduces the burden to explain return values), and annotation-rich context, the description is minimally complete. However, it lacks any edge-case behavior (e.g., removing the last admin permission from a course, or deleting a non-existent permission). The presence of many sibling permission tools (get/post/delete for various entities) makes the absence of differentiation a gap.

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% – every parameter (user, course, permission) has a description in the input schema. The description adds no further meaning beyond restating the operation. Baseline 3 is appropriate since the schema already documents the parameters well, though the description could explain how permission removal differs or any ordering assumptions.

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 "Remove a user permission from a course", which is a clear verb+resource that specifies exactly what is removed (a user permission) and from where (a course). Among siblings like edubase_get_course_permission and edubase_post_course_permission, this delete variant is sufficiently distinct, though it does not explicitly differentiate from other permission delete tools like edubase_delete_class_permission or edubase_delete_quiz_permission.

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 guidance on when to use this tool vs alternatives (e.g., edubase_post_course_permission to add, edubase_delete_class_permission for class-level removal). It lacks any context about prerequisites, such as whether the user must already have the specific permission, or when it is safe to call (e.g., only if the user has 'grant' authority). There are no exclusions or explicit usage conditions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's statement 'Remove' is consistent but adds no new behavioral insight. It does not disclose whether the operation is reversible, if the tag must already be attached, or any side effects. With the burden already lowered by annotations, the description contributes minimal additional transparency.

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, tight sentence that immediately communicates the tool's action and target. There is no extraneous information, and it is well front-loaded.

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's simplicity (two required string parameters, high schema coverage, an output schema present), the description is largely complete. It could optionally note that the tag must be currently attached to the course, but this is a minor gap. Overall, it sufficiently covers the operation for a straightforward deletion task.

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 100% (both 'course' and 'tag' have descriptions like 'course identification string'). The description adds no further parameter meaning beyond what the schema provides, so it meets the baseline for high coverage without adding value.

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 'Remove a tag attachment from a course' uses a specific verb ('Remove') and clearly identifies the resource ('tag attachment') and context ('from a course'). This distinguishes it from sibling delete_*_tag tools which target other entities like class, exam, or event.

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 implies usage through the resource context ('course'), but it provides no explicit guidance on when to use this tool versus alternatives (e.g., delete_class_tag) nor any exclusions or prerequisites. The usage is implied but not articulated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds nothing beyond the literal 'remove'. It does not clarify that the user must still be attached to the event, whether the operation fails if the permission doesn't exist, or if there are cascading effects. The description fails to add behavioral context beyond the annotations.

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 short sentence with no waste. It is appropriately front-loaded for quick scanning. However, it could be slightly improved by adding a brief note on effect or prerequisites without becoming verbose.

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 presence of an output schema and the simplicity of a 3-parameter delete operation, the description is minimally adequate but lacks guidance on error handling or preconditions. It does not explain the return value (if any) beyond what the output schema might convey, but that is acceptable with an output schema present.

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 the input schema already documents all three parameters: event, user, and permission. The description simply repeats the title and does not add any usage notes on parameter constraints (e.g., whether user must be an ID string versus email). Baseline 3 is appropriate since the schema does the heavy lifting.

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 action ('Remove') and the object ('a user permission from an event'), using a specific verb and resource. While it distinguishes this as a deletion tool among the many permission siblings (e.g., edubase_get_event_permission, edubase_post_event_permission), it could be more precise by noting it removes a specific permission record, not the user from the event entirely.

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 guidance on when to use this tool versus alternatives like edubase_post_event_transfer or other permission delete tools. It does not mention prerequisites (e.g., needing admin or grant permission) or when a user should have no remaining permissions, leaving the agent without use-case context.

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

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

The description adds no behavioral context beyond what the annotations already convey. Annotations already specify 'destructiveHint: true' and 'idempotentHint: true'. The description does not clarify what happens if the tag or event does not exist, nor any side effects. It simply restates the action.

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 sentence with no wasted words, achieving conciseness. However, it lacks structural elements like context or usage notes. For a simple delete tool, this is acceptable but not exceptional.

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 existence of an output schema and the annotations covering idempotency and destructiveness, the description is minimally adequate. It does not address potential error cases (e.g., non-existent tag) or the idempotent nature, leaving some gaps for an AI agent to infer.

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% with both parameters having descriptions ('tag identification string', 'event identification string'). The tool description does not add any additional meaning or usage hints for the parameters beyond the schema, so the 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 'Remove a tag attachment from an event' uses a specific verb ('remove') and clearly identifies the resource ('tag attachment from an event'). It distinguishes this tool from siblings like 'edubase_post_event_tag' (add tag) and 'edubase_delete_event_permission' (different resource).

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or direct users to sibling tools like 'edubase_post_event_tag' for adding tags. The usage context is only inferred from the tool name and sibling list.

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

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

Annotations already declare the tool as destructive and idempotent. The description adds no extra behavioral context (e.g., whether archiving is reversible, side effects on related data).

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 extremely concise (3 words), which is efficient, but it sacrifices informativeness. It could be expanded without losing brevity.

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 no output schema, the description should clarify what happens after deletion (e.g., return value, success indicator). It also fails to differentiate from numerous sibling delete tools.

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 only parameter 'exam' is described in the schema as 'exam identification string'. The tool description does not elaborate on the format, source, or how to obtain it, adding no value beyond the schema.

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 'Remove/archive exam,' which indicates the action, but the term 'archive' is ambiguous (soft delete vs. hard delete). It does not differentiate from many sibling delete tools, leading to moderate clarity.

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?

No guidance on when to use this tool vs. alternatives, no prerequisites mentioned, and no exclusions provided. The agent has no context for appropriate invocation.

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

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

Annotations already indicate destructive behavior (destructiveHint: true), and the description adds valuable specifics: 'The PIN code and the shortlink of the exam are removed as well.' This discloses concrete side effects beyond the generic annotation, giving the agent a clearer picture of the operation's impact.

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 two concise sentences: the first states the core action, the second adds the critical side effect. There is no redundant or extraneous information, making it efficiently structured and easy to parse.

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 tool with one parameter and no output schema, the combination of description, annotations, and parameter schema covers the essential operational aspects. The description adequately explains the primary effect and key side effects, though it does not mention how to re-enable automatic login or any permission prerequisites, which are minor omissions given the annotations.

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 single parameter 'exam' is fully described in the schema as 'exam identification string', so schema description coverage is 100%. The tool description does not add any additional parameter semantics, which aligns with the baseline score for high coverage.

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 action: 'Disable automatic login for an exam' and specifies the side effect of removing the PIN code and shortlink. This distinguishes it from siblings like edubase_post_exam_autologin and edubase_get_exam_autologin, leaving no ambiguity about its purpose.

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 does not explicitly state when to use this tool or mention alternatives, such as edubase_post_exam_autologin for enabling login. However, the tool's specific name and action make its use case reasonably implicit, providing minimal guidance beyond the operation itself.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context (e.g., what happens if no branding exists, permission requirements, reversibility). It is adequate but not informative beyond the structured fields.

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 with no filler. It is front-loaded and efficiently communicates the core action.

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 simple destructive tool with one parameter and no output schema, the description is minimally sufficient. However, it lacks details on edge cases (e.g., non-existent branding) and prerequisites, which would improve completeness.

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 one parameter 'exam' with description 'exam identification string', covering 100% of parameters. The description does not add any extra meaning or constraints beyond the schema, resulting in a baseline score of 3.

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 'Remove branding from an exam' uses a specific verb ('Remove'), identifies the resource ('branding'), and clearly distinguishes from sibling tools like edubase_delete_exam (deletes entire exam) and edubase_post_exam_branding (adds branding).

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?

No guidance is provided on when to use this tool vs alternatives (e.g., edubase_delete_exam, edubase_post_exam_branding). There is no mention of prerequisites, idempotency, or typical use cases.

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

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

Despite the annotations already indicating destructive and idempotent behavior, the description adds valuable context beyond them: it states that built-in fields are kept, that examinee-entered values are retained but hidden, and that the view_results_identifier setting is cleared. These are nontrivial side effects that the annotations do not convey. No contradiction exists.

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 four sentences, each delivering a distinct piece of information: primary action, built-in field exceptions with a pointer to the alternative, data retention behavior, and settings clearance. It is front-loaded with the core action and contains zero filler. Ideal length for the complexity.

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?

The description completely covers the tool's effects: what is removed, what is kept, what happens to existing values, and what settings are affected. Given only one parameter and no output schema, no additional context is needed for an agent to invoke the tool correctly. The annotations cover the destructive nature, so nothing essential is missing.

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% description coverage for the single 'exam' parameter, so the schema already fully documents the parameter. The description does not add any extra semantic detail about the parameter itself (e.g., format or constraints). Baseline 3 is appropriate since the schema carries the full burden.

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 opens with a specific verb and resource: 'Remove every custom field of an exam.' It clearly states the scope (all custom fields), differentiates from related tools like edubase_post_exam_fields by specifying what is kept vs. what is removed, and notes the side effect on view_results_identifier. This leaves no ambiguity about what the tool does.

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 explicitly names the alternative tool for a different use case: 'use edubase_post_exam_fields to turn those off' (the built-in fields). This provides clear when-to-use and when-not-to-use guidance, telling the agent that this tool is for removing custom fields while preserving built-in ones, and directing to the sibling for the opposite need.

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

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

The annotations already declare destructiveHint=true and idempotentHint=true. The description adds little beyond that. It does not clarify what happens to dependents, whether the user must still exist, or that the operation is irreversible. For a destructive tool, more behavioral context would be valuable, but the annotation covers the basic intent.

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 sentence of only 5 words, perfectly front-loaded, and contains zero filler. Every word serves a purpose: 'Remove' conveys the action, 'user permission' the target, and 'from an exam' the scope. This is maximally concise while still being complete.

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?

With 100% schema coverage, an output schema present, and annotations clarifying destructive/idempotent behavior, the description is adequate for a straightforward delete operation. It could optionally mention that this mirrors a sibling 'post_exam_permission' or that the permission value must match an existing assignment, but the essential information is conveyed.

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%, with each parameter having clear descriptions. The description verb 'Remove' adds the context that this is a deletion operation, which is consistent with the parameters (exam, user, permission). No additional parameter semantics are needed beyond what the schema provides.

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 the specific verb 'Remove' and clearly identifies the resource as 'a user permission from an exam.' This directly distinguishes it from siblings like 'edubase_post_exam_permission' (add permission) and 'edubase_get_exam_permission' (list permissions), making the tool's purpose unmistakable.

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 tool involves removing a permission, and the destructiveHint annotation implicitly warns about potential impact. However, the description does not explicitly state when to use this tool over alternatives (e.g., editing permissions via post_exam_permission) or any prerequisites (like the exam must exist). The agent gets the basic action but lacks context on appropriate invocation.

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

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

The description aligns with annotations: destructiveHint=true (removing a tag is destructive) and idempotentHint=true (removing an already removed tag likely does nothing). The openWorldHint=true may be questionable since the tool requires both exam and tag IDs, but it does not contradict. The description adds value by explicitly stating 'tag attachment' (implying it only removes the association, not the tag itself), which is beyond the annotations.

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, well-structured sentence that clearly states the operation. No wasted words – every word earns its place. Front-loaded with the action, it communicates effectively.

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's complexity (2 required params, no enums, output schema present) and the availability of sibling tools like edubase_delete_exam_tag (contrast with edubase_post_exam_tag), the description is complete enough for a simple associative removal. However, it lacks context about side effects (e.g., does this affect the exam's behavior or other tags?) and return values. With an output schema present, return values are clarified by schema, but behavior details could be richer.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining that the tool removes a 'tag attachment' (not the tag itself), which clarifies semantics for the two required parameters (exam and tag). However, it does not elaborate on format, source, or validation rules for parameters.

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 'Remove a tag attachment from an exam' uses specific verbs ('Remove') and resources ('tag attachment', 'exam') to clearly define the tool's action. It distinguishes this tool from 'edubase_post_exam_tag' (which would add a tag) and other delete tools like 'edubase_delete_exam', making the purpose unambiguous.

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 does not specify when or when not to use this tool. It does not mention alternatives like 'edubase_tag' operations for removing tags from other entities, but the implicit context suggests it is for exam tags only. No explicit guidance on prerequisites (e.g., tag must already exist) or disclaimers about side effects.

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

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

Annotations indicate destructive, idempotent, and open-world hints, but the description only repeats 'remove' with no additional context on permanence, cascading effects, or side effects. Misses opportunity to explain what 'remove' entails.

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?

Single sentence with no redundant words. Front-loaded with action and resource.

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?

Lacks information about return values, reversibility, or impact on exam state. Given no output schema and destructive nature, more context is needed for safe use.

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 100%, with descriptions for both 'exam' and 'users'. The description adds no additional semantic meaning beyond the inline parameter descriptions, meeting the baseline but not exceeding it.

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 'Remove user(s) from an exam' uses a specific verb and resource, clearly distinguishing it from sibling tools like edubase_delete_exam (deletes the exam itself) or edubase_post_exam_users (adds users).

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?

No guidance on when to use this tool versus alternatives like edubase_delete_class_members or edubase_post_exam_users. No prerequisites or usage conditions mentioned.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description restates the delete action but adds no new behavioral info beyond what annotations provide.

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?

Single sentence, no unnecessary words. Efficient and direct.

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?

Complete enough for a simple delete operation with annotations. However, the 'and/or' could be clarified (e.g., whether deleting both requires separate calls).

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 100% with a clear parameter description. The tool description adds no additional meaning beyond the schema for the single parameter.

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 action (Delete) and the resource (uploaded file and/or temporary file upload link). It is specific and distinguishes from other delete tools among siblings.

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?

No guidance on when to use this tool vs. alternatives, no prerequisites or context for usage provided. Simply states the action without usage context.

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

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

The description merely repeats the destructive nature already indicated by the annotation destructiveHint=true. It adds no extra behavioral context such as whether deletion triggers cascading effects, if it can be undone, or if special permissions are required. The annotations already declare readOnlyHint=false and destructiveHint=true, so the description adds no value.

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 very short ('Remove integration.') but lacks informative content. While concise, it is under-specified for a delete operation. The single sentence does not fully earn its place as it repeats the tool name's intent without adding helpful detail.

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 destruction operation with one required parameter and no output schema, the description is incomplete. It does not explain post-deletion effects, whether related resources (e.g., integration tags) need to be removed first, or what happens if the integration is in use. The sibling tool edubase_delete_integration_tag suggests dependency, but no guidance is given.

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 provides a description for the 'integration' parameter ('integration identification string'), achieving 100% schema coverage. Per the scoring guidelines, the baseline is 3 when coverage is high. However, the description adds no further meaning about the parameter's format, source, or constraints beyond the schema.

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 'Remove integration,' specifying the verb (remove) and resource (integration). It distinguishes from sibling tools that operate on other resources (e.g., edubase_delete_question, edubase_delete_exam), but lacks additional context about what kind of integration this refers to.

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?

No guidance is provided on when to use this tool versus alternatives like edubase_patch_integration (update) or edubase_post_integration (create). There are no conditions, prerequisites, or exclusions mentioned.

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

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.

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

Annotations already provide: destructiveHint=true (indicates mutation), idempotentHint=true (safe to retry), openWorldHint=true. The description adds 'Remove', confirming the destructive nature. However, it doesn't elaborate on what happens upon success or failure, or if there are cascading effects (e.g., if the tag itself is deleted). Given annotations cover most safety info, this is adequate but not exceptional.

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 one short sentence, which is concise. However, it is arguably too brief for a tool that requires two parameters and has many siblings. It could benefit from additional context in a second sentence without being wordy.

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 an output schema (not shown) and 100% parameter coverage, the description is adequate but not complete. It doesn't clarify return values (though output schema may handle that) or edge cases. For a delete operation, it provides the minimal information.

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 100%, so the baseline is 3. The description does not add any extra meaning for the parameters beyond what the schema provides ('tag identification string', 'integration identification string'). The tool name clarifies which IDs are needed, but the description adds no value for parameter semantics.

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 action ('Remove a tag attachment') and the target resource ('an integration'). This distinguishes it from sibling tools like 'edubase_post_integration_tag' (which adds a tag attachment) and 'edubase_delete_integration' (which deletes the integration itself). The verb 'Remove' is specific and unambiguous.

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. For instance, there is no mention that this is for removing a tag that was previously attached via 'edubase_post_integration_tag', or any prerequisites like needing an existing tag attachment. The context signals show many sibling tag-related tools, but the description offers no differentiation hints.

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

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

Annotations provide destructiveHint=true, idempotentHint=true, openWorldHint=true. Description adds no behavioral context beyond what annotations already convey.

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-word description is under-specified, not concise. Lacks structure and front-loading of key information.

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?

Description omits critical details like side effects, permission requirements, and return behavior. Inadequate for a destructive operation.

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?

Parameter schema has 100% coverage, but description 'Remove organization.' adds no meaning to the 'organization' parameter beyond its schema description.

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?

Description 'Remove organization.' is vague but conveys the basic action of deleting an organization. It does not differentiate from similar sibling tools like edubase_delete_organization_members.

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?

No guidance on when to use this tool, prerequisites, or consequences. Does not mention alternatives or conditions for use.

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

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

The description only restates the basic action. Annotations already signal destructive, idempotent, open-world behavior but the description adds no details about outcomes (e.g., success/failure, remaining members, reversibility).

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, efficient sentence with no redundant words, achieving maximum conciseness while conveying the core purpose.

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?

The description is insufficient for a destructive tool with no output schema. It omits return value, side effects, and any context about what happens after removal, such as error handling or confirmation.

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 schema already describes both parameters (organization and users as comma-separated strings) with 100% coverage. The description adds no additional context beyond the schema definitions.

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 'Remove user(s) from an organization' clearly states the action and target, distinguishing it from sibling delete tools like edubase_delete_organization and edubase_delete_organization_permission.

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 (e.g., edubase_post_organization_members for adding, or edubase_get_organization_members for reading). No preconditions or exclusions are mentioned.

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

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

Annotations already declare destructiveHint: true and idempotentHint: true, informing the agent the tool is mutating but safe to retry. The description does not add behavioral context beyond this—it doesn't note, for instance, whether removing a permission cascades to sub-resources or requires specific user roles. With annotations covering the key traits, a score of 3 is appropriate.

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, clear sentence that efficiently conveys the tool's purpose with no unnecessary words. It is appropriately front-loaded and easy to parse. A slightly longer description that included minor usage guidance (e.g., related tools) would still be acceptable, but the current version is lean and effective.

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's simplicity (3 required params, all string, no nested objects) and the presence of an output schema, the description is functional but lacks context about the permission removal process (e.g., what happens if the user doesn't have the permission, or if the permission is the last one). The sibling tools for post/get/delete are similar, so the description is minimally adequate but not enriched with situational nuance.

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 the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (user, permission, organization). It does not explain the relationship between parameters or provide examples, but the schema already provides clear enum values for permission and basic descriptions for each field.

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 action ('Remove') and the resource ('user permission from an organization'), distinguishing it from sibling tools like edubase_post_organization_permission (which adds a permission) and edubase_get_organization_permission (which retrieves them). The verb and target are specific and unambiguous.

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 clear context by stating the tool removes a permission, but it does not provide guidance on when to use it versus alternatives (e.g., it does not mention that to add a permission, one should use edubase_post_organization_permission, or that the permission must already exist). No explicit exclusions or prerequisites are stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description carries a lower burden. The description adds no extra behavioral context (e.g., effect of removing a non-existent tag, side effects, or reversibility). It is adequate but adds no value beyond annotations.

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, clear sentence. It is concise but could be slightly expanded to include usage guidelines or behavioral notes without losing brevity. No wasted 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 tool's simplicity (two parameters, no enums, output schema present), the description is sufficient for a basic understanding. However, it lacks guidance on when to use this specific delete tool among many similar siblings, which would improve completeness.

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%, with both parameters described as 'identification string'. The description does not add any additional meaning, format, or usage hints beyond the schema. 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 'Remove a tag attachment from an organization' uses a specific verb ('Remove') and resource ('tag attachment from an organization'), clearly distinguishing this tool from sibling tools like edubase_post_organization_tag (add) and other entity-specific delete_tag tools.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., edubase_delete_class_tag, edubase_delete_course_tag). The description does not mention when to use, when not to use, or prerequisite conditions.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description 'Remove' aligns but adds no additional behavioral context (e.g., irreversibility, permission requirements). No contradiction with annotations.

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 three words and to the point, but it is arguably too terse, missing any qualifying detail. It earns its place with no fluff.

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 simple delete operation with well-defined parameters and no output schema, the description is minimally adequate. However, it lacks context on side effects or impact, such as whether deleting a webhook triggers any actions.

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 100% with descriptions for both parameters. The description adds no further meaning beyond the schema, so baseline 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 'Remove organizational webhook' uses a specific verb ('Remove') and clearly identifies the resource ('organizational webhook'), distinguishing it from sibling tools like edubase_delete_organization or edubase_delete_organization_members.

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?

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context for deletion, or when not to use it (e.g., if webhook is in use).

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's emphasis on 'Permanently' adds minimal value. The description repeats the destructive nature without providing additional behavioral details like cascading effects or required permissions.

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, direct sentence with no unnecessary words. It efficiently conveys the core action and resource.

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 simplicity of the tool (single parameter, no output schema), the description is sufficient. However, it could be improved by mentioning that deletion is irreversible or that the question must belong to a quiz, but lacks such context.

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 covers 100% of parameters with a clear description ('external unique question identifier'). The tool description does not add any further meaning or usage hints beyond what the schema provides, resulting in no added value.

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 'Permanently delete a Quiz question', which is a specific verb-resource pair. Among many sibling delete tools, this explicitly targets quiz questions, distinguishing it from other delete tools like 'edubase_delete_quiz' or 'edubase_delete_exam'.

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 explicit guidance on when to use this tool versus alternatives, such as when to use 'edubase_delete_quiz_questions' for bulk deletion. The tool name and context imply its usage for deleting a single question, but no exclusions or prerequisites are stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no further behavioral details, such as whether the deletion is permanent, reversible, or cascades to associated data (e.g., questions). With annotations covering the basics, the description fails to provide additional context about side effects or recovery options.

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 brief sentence, which is concise. However, it sacrifices useful content (e.g., usage guidelines, behavioral notes) for brevity. Every sentence should earn its place; this one is functional but could be expanded to include more guidance without becoming verbose.

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 simplicity of the tool (one parameter, no output schema), the description is minimal but misses context about what happens upon deletion (e.g., permanent vs. archival, impact on related permissions or questions). The presence of many sibling delete tools increases the need for clearer context to avoid misuse.

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 already describes the sole parameter (quiz) as 'Quiz identification string', achieving 100% coverage. The description does not add extra meaning or format hints beyond what the schema provides, so 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 'Remove/archive Quiz set' clearly identifies the action (remove/archive) and the resource (Quiz set). It is specific and distinguishes the tool from many sibling delete tools that target other entities (e.g., quiz questions, permissions). However, the slash may imply ambiguity between removal and archiving, slightly reducing clarity.

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?

No guidance is provided on when to use this tool versus alternatives like edubase_delete_quiz_questions or edubase_delete_quiz_permission. The description does not specify prerequisites or context for use, leaving the agent to infer from the resource name alone.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds important behavioral context by listing the conditions that prevent deletion (global presets, in-use presets), which governs when the operation will succeed or fail. It also aligns with idempotentHint=true since attempting to delete an already-deleted preset would likely be idempotent. No contradiction with annotations.

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, tightly worded sentence that states the action and immediately provides the key constraints. There is zero wasted text, and the critical limitation is introduced upfront. This is an exemplary concise structure.

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?

The tool is simple: one parameter, no output schema, and annotations covering the safety profile. The description provides the essential operational constraint (what cannot be removed) that an agent must know before calling. Nothing needed for successful invocation is missing; the agent can safely call this without further context.

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 schema has 100% coverage for the single parameter 'preset', described as 'grading preset identification string'. The description does not add further detail about the parameter format or how to obtain it, but the schema already provides sufficient semantic meaning. Baseline of 3 is appropriate since the description does not need to compensate.

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 verb and resource: 'Remove a custom grading preset.' It also specifies the scope (custom) and immediately distinguishes itself from other deletion tools like edubase_delete_quiz or edubase_delete_quiz_questions by targeting a unique resource type. The title annotation reinforces the purpose without conflicting.

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 explicitly states when NOT to use the tool: global presets and presets used by a Quiz set or exam cannot be removed. This gives the agent a clear boundary for usage. It does not explicitly name an alternative or state 'use this when...' but the exclusion criteria effectively guide the agent on valid conditions. No sibling tool directly overlaps in function.

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

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

Annotations already declare destructiveHint=true, so the agent knows removal is irreversible. The description confirms this operation is destructive, but adds no additional behavioral context beyond the annotations. For example, it doesn't disclose whether dependent objects (like quiz results) are affected, whether cascade deletion occurs, or if specific authorization (e.g., 'admin' permission) is required. The description does not contradict the annotations; thus no contradiction flag.

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, clear sentence with no filler. It is front-loaded with the action and resource. However, it could be slightly expanded (e.g., clarifying scope or side effects) without sacrificing conciseness.

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?

The tool has a clear purpose, 3 required params, a known output schema (present but not described), and annotations that convey destructiveness. The description is adequate for a simple deletion tool, but it lacks any mention of the output (e.g., what the response looks like) or edge cases (e.g., removing a non-existent permission). Given the output schema exists, explaining the return value is not required, but the description still feels minimal.

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 100% – all three required parameters (quiz, user, permission) are described in the schema. The description does not add any additional parameter semantics (e.g., what format quiz or user IDs should follow, what permission values are valid beyond the enum). Since the schema is complete and the description is brief, 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 'Remove a user permission from a quiz' uses the specific verb 'Remove' and clearly identifies the resource (user permission on a quiz). It distinguishes this tool from sibling operations like edubase_post_quiz_permission (add) and edubase_get_quiz_permission (list). However, it does not clarify whether this is a soft delete, revocation, or outright removal, which would strengthen clarity.

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?

No guidance on when to use this tool versus alternatives. There are sibling tools for adding (edubase_post_quiz_permission) and listing permissions (edubase_get_quiz_permission), but the description does not mention these alternatives or specify prerequisites (e.g., 'user must have existing permission'). The agent must infer usage context entirely from the name and schema.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the context that removal can target a specific group, but it does not disclose other behavioral traits like whether removal is permanent or what happens to the question entity itself.

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 sentence that efficiently conveys the action and scope with no redundant words. It is front-loaded with the verb and object.

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?

While the description covers the basic operation, it lacks details about return values (no output schema), reversibility, or effects on dependent objects. For a destructive tool, more context would be beneficial.

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 100% with basic descriptions for each parameter. The tool description does not add further meaning, such as how to obtain the identifiers or the format required, so it meets the baseline but does not enhance 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 specifies the verb 'Remove' and the resource 'question(s) from a Quiz set, or one of its question group', which clearly distinguishes it from sibling tools like edubase_delete_question (which likely deletes the question entity entirely). The scope is precise.

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 such as edubase_delete_question or other delete tools. It does not mention when not to use it or any prerequisites.

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

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

Even with destructiveHint=true in the annotations, the description adds substantial nuance: archiving makes the result disappear from lists/reports but keeps it restorable by adding the user back; forgetting detaches the play from the user but keeps it for statistics. It also discloses admin-only requirement for non-exam results. This goes well beyond a raw destructive flag and gives an accurate mental model of side effects.

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?

Five sentences, each essential: main purpose, the two behavioral branches, the archive-enabling prerequisite, the current-result restriction, and the admin-only restriction. The prose is dense but well-structured, with no fluff or redundant restatement of the title/name.

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?

The description fully equips an agent to invoke the tool correctly: it explains what happens in both exam and non-exam scenarios, names the prerequisite setting and its source, notes the current-result limitation, and states permission requirements. Given no output schema exists, the state-change explanation is sufficient; there are no obvious missing critical details.

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 already covers 100% of the parameter with 'play' described as 'Quiz play identification string.' The description does not enrich the parameter's meaning (e.g., how to obtain the play ID or expected format), so the schema does the heavy lifting. Baseline 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 opens with 'Archive or forget the result of a Quiz play,' providing a clear verb (archive/forget) and specific resource (a Quiz play's result). It then explains two distinct outcome modes (exam result vs. outside exam), making it unambiguous what the tool does and distinguishing it from generic delete_quiz or delete_exam tools.

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 concrete usage constraints: exam results can only be archived when the archive setting is enabled (referencing edubase_post_exam_settings), only the current result can be archived, and non-exam results can only be forgotten by administrators. These communicate when the tool is applicable. However, it does not explicitly point to an alternative tool for a comparable action, so it stops short of a full 5.

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

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

Annotations provide rich behavioral hints: destructiveHint=true (deletion), idempotentHint=true (safe to retry), and readOnlyHint=false (mutating). The description corroborates the destructive nature by stating 'Remove', adding no contradiction. Together, they offer strong transparency. The description does not add new behavioral details beyond annotations, but the annotations already carry the load well.

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, clear sentence that directly states the purpose with no extraneous words. It is perfectly sized for its function and front-loaded with the action.

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 low complexity (2 params, both required, no enums, no nested objects), the description plus annotations and output schema provide sufficient completeness. The presence of an output schema means return values need not be described. However, missing details like prerequisites (e.g., does the tag need to exist?) slightly lower the score.

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 100%, so parameters 'quiz' and 'tag' are defined in the schema with basic descriptions. The description adds no additional meaning (e.g., format, constraints, or how tag is identified), thus does not enhance beyond the schema baseline.

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 action (Remove) and the resource (tag attachment from a Quiz). It distinguishes the tool from siblings like edubase_post_quiz_tag (add tag) and edubase_delete_quiz (delete whole quiz), though it does not explicitly differentiate from other tag deletion tools like edubase_delete_course_tag.

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 minimal description implies use when a tag needs to be removed from a quiz, but provides no guidance on when not to use it (e.g., if the tag is shared or required), nor does it suggest alternatives like edubase_post_quiz_tag for adding or edubase_delete_quiz for deletion of the entire quiz.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no extra behavioral context beyond 'Remove', such as error behavior on missing entities, reversibility, or side effects. With annotations covering the safety profile, the description provides minimal added value.

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, front-loaded sentence of 10 words. It is concise but not overly terse; it could include a bit more context (e.g., 'revoke' instead of 'remove') without becoming verbose. It earns its place by stating the action clearly.

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?

The description is too minimal for a destructive tool with 3 required parameters. It does not explain the return value (output schema exists but is not referenced), nor does it mention that the permission must be from the enumerated list (though schema covers that). Given the richness of sibling tools, the description lacks completeness to fully guide an agent.

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 the input schema already documents all three parameters. The description does not add any additional meaning or usage hints beyond what the schema provides. Baseline 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 uses a specific verb ('Remove') and clearly identifies the resource ('user permission from a SCORM learning material'). It distinguishes from sibling tools like edubase_get_scorm_permission (read) and edubase_post_scorm_permission (add), making the tool's action unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., edubase_delete_quiz_permission, edubase_delete_exam_permission) or what prerequisites exist (e.g., user must exist, SCORM must exist). The description is silent on when-not-to-use and does not mention any context or exclusions.

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

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

Annotations declare destructiveHint=true, so the description does not need to restate that. The description adds no additional behavioral context (e.g., what happens to the SCORM material, required permissions, or error states). With annotations already covering the destructive nature, the description's minimalism is acceptable but misses an opportunity to add value.

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 conveys the core action and resource. It is front-loaded and efficient, with no unnecessary words. However, it is so brief that it could benefit from a tiny bit more context without becoming verbose.

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 that there is an output schema, return values need no explanation. The tool has only two simple required parameters and no enums or nested objects. The description, combined with the schema and annotations, is minimally complete for a basic deletion operation, but additional context about prerequisites or side effects would improve completeness.

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%, and both parameters ('scorm' and 'tag') are fully documented in the schema with their descriptions ('SCORM identification string', 'tag identification string'). The description adds no further parameter context beyond what the schema provides, so 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 uses a specific verb ('Remove') and a clear resource ('tag attachment from a SCORM learning material'). It accurately distinguishes from siblings like edubase_get_scorm_tag (read) and edubase_post_scorm_tag (create), making the tool's purpose unambiguous.

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 does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tag tools. Usage context is only implied by the tool's name and description, which is adequate for a straightforward remove operation but lacks differentiation from other tag deletion tools.

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

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

Annotations already provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no behavioral context beyond stating the action of removing. It does not describe side effects, edge cases (e.g., removing a non-existent permission), or authentication needs. Since annotations carry the burden, a score of 3 is appropriate.

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 extremely concise—a single six-word sentence that communicates the core purpose without any unnecessary text. It is front-loaded and leaves no filler, earning top marks for efficiency.

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 having an output schema, the description lacks essential context for a destructive operation. It does not explain what happens upon success or failure, whether the tool requires specific permissions, or how it behaves if the permission doesn't exist. The minimal description leaves significant gaps for an agent.

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?

All three parameters (tag, user, permission) are fully described in the schema with clear descriptions and an enum for permission. The description adds no extra parameter meaning or formatting hints. With 100% schema coverage, a baseline score of 3 is justified.

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 'Remove a user permission from a tag.' uses a specific verb ('Remove') and clearly identifies the resource (user permission) and target (tag). It distinguishes well from sibling tools like edubase_get_tag_permission and edubase_post_tag_permission, leaving no ambiguity about what this tool does.

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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or distinguish itself from other delete_permission tools for different entities (e.g., edubase_delete_exam_permission). An agent would need external knowledge to choose correctly.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds no behavioral context, such as whether the deletion is soft or hard, or any side effects. It does not exceed what annotations provide.

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 extremely concise (two words), but it is under-specified. It does not provide enough information to be useful, sacrificing completeness for brevity.

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 deletion tool with one parameter and no output schema, the description is incomplete. It does not explain what constitutes a user identification string, nor any consequences of deletion. The tool needs more context for safe use.

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 schema covers 100% of parameters (one required 'user' string with a brief description). The description adds no extra meaning beyond the schema, so a baseline 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 states 'Delete user,' which is a specific verb+resource. It distinguishes from siblings that delete other entities (e.g., edubase_delete_class_members), but does not provide any additional context or 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?

No guidance is given on when to use this tool versus alternatives like edubase_delete_user_classes or edubase_delete_user_assume. The description lacks any context or exclusions.

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

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

Annotations indicate destructiveHint=true and idempotentHint=true, but the description merely repeats the title without adding context about what revocation entails (e.g., token invalidation, effect on sessions). No behavioral detail beyond annotations.

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 very concise (5 words) and front-loaded. However, the brevity sacrifices some clarity about the token's nature.

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 destructive nature and no output schema, the description should explain the effect (e.g., token becomes invalid) and any prerequisites. It lacks this context.

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 provides 100% coverage with a single 'token' parameter described as 'assume token'. The description adds no additional semantics, format, or origin information for the token.

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 'Revoke assume token' clearly states the action (revoke) and resource (assume token). However, it does not differentiate from similar sibling delete tools, such as edubase_delete_user_login, which might also involve tokens.

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?

No guidance is provided on when to use this tool versus alternatives like edubase_post_user_assume (which creates tokens) or edubase_delete_user_login. There is no context for appropriate usage scenarios.

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

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

Annotations indicate destructiveHint: true and idempotentHint: true, so the description correctly implies a destructive action. The description aligns with annotations (no contradiction). However, it does not add behavioral detail beyond what annotations already convey, such as whether the tool permanently deletes data or just removes associations.

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 with no fluff. It is front-loaded with the action and resource. Minor improvement would be to clarify the relationship between the two parameters.

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's moderate complexity (2 required params, no output schema, no nested objects), the description is minimally adequate. It tells what it does but not the effect on the system, prerequisites (e.g., user must be in class), or side effects. Sibling tools exist for adding users to classes, so cross-reference would help.

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% for both parameters ('user identification string', 'comma-separated list of class identification strings'). The description adds no extra meaning beyond what the schema provides, so baseline 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 verb 'remove' and the resource 'user from class(es)'. It distinguishes from sibling tools like edubase_delete_user (removes the user entirely) and edubase_post_user_classes (adds user to classes). However, it could be more specific by stating it removes the user's membership, not just the user.

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 vs alternatives. Among siblings, there is edubase_post_user_classes (add) and edubase_delete_class_members (remove from a single class), which are related. No mention of when to prefer this over those or vice versa.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, so the description's statement about deletion is consistent. However, it does not add significant behavioral context beyond what annotations provide, such as whether the link becomes immediately invalid or if there are any side effects. The description is adequate but minimal.

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, direct sentence that conveys the essential purpose without any extraneous words. It is optimally concise and front-loaded appropriately.

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's simplicity (2 parameters, no output schema, no nested objects) and the presence of annotations, the description covers the basic functionality. However, it does not explain the effect (e.g., link becomes invalid, returns success) or any required context like needing the user ID. It is minimally acceptable but could be more 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?

The input schema has 100% description coverage with clear explanations for both parameters ('user identification string' and 'generated login link to be invalidated'). The description does not add any extra meaning beyond the schema, so it meets the baseline for this dimension.

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 action ('Delete') and the resource ('previously generated login link'). Among many sibling delete tools, this one is uniquely identified by targeting login links, distinguishing it from others like edubase_delete_user or edubase_delete_class_members.

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. For example, it does not mention whether to use this over edubase_delete_user (which deletes the user account) or other delete tools. No context about prerequisites or typical use cases is given.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. Description adds no further behavioral context (e.g., cascading effects, required user permissions, or whether relationships beyond membership are affected). It doesn't contradict annotations.

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?

Extremely concise: a single sentence of 5 words. No fluff or redundancy. Every word earns its place.

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?

Simple tool with 2 required params and no output schema, but description lacks scope details (e.g., 'Remove user from one or more organizations? Completely or partially?'). Returns/consequences are not mentioned. Incomplete for guiding an agent on expected outcomes.

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 parameters are already documented. Description adds no additional meaning about 'user' or 'organizations' beyond their schema descriptions (e.g., no format, validation rules, or constraints). Baseline 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?

Description clearly states verb (remove) and resource (user from organization(s)). It's concise and unambiguous, distinguishing its destructive removal purpose from sibling tools like edubase_post_user_organizations (add) and edubase_get_user_organizations (list).

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?

No guidance on when to use this tool vs alternative removal methods (e.g., edubase_delete_organization_members or edubase_delete_user_classes). No prerequisites or conditions for removal are mentioned.

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

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

Annotations already provide destructiveHint=true and readOnlyHint=false, which the description aligns with ('Remove'). However, the description adds no additional behavioral details beyond the annotations. For example, it does not explain idempotency (annotated idempotentHint=true) or what happens when the permission does not exist. The description carries minimal extra value.

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 sentence of six words, making it very concise and front-loaded. It wastes no words but could be slightly more informative without sacrificing conciseness. The structure is adequate for a simple 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?

Given the tool has three required parameters, an output schema, and annotations (including openWorldHint and idempotentHint), the description is too minimal. It does not clarify the behavior when the permission is missing, the format of the response, or any side effects. The output schema is present but not referenced, leaving the agent without full context for correct invocation. More information about idempotency and expected outcomes would improve completeness.

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%, and the schema already provides descriptions for all three parameters (user, video, permission). The tool description does not add any additional meaning or context for these parameters, so it meets the baseline of 3. No extra clarity is provided beyond the schema.

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 'Remove a user permission from a video' clearly states the action (remove) and the resource (user permission on a video). It readily distinguishes from sibling delete tools (e.g., delete_exam, delete_user) by specifying the resource type. However, it does not explicitly differentiate from the sibling 'edubase_delete_video_permission' itself, but the name makes the resource clear.

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?

No guidance is provided on when to use this tool versus alternatives like edubase_post_video_permission (add) or edubase_get_video_permission (view). There is no mention of prerequisites, required permissions, or scenarios where deletion is appropriate. The description is purely functional, lacking any context about when to invoke it.

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

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

The annotations provide strong behavioral cues: destructiveHint=true clearly indicates a destructive/mutating operation (removing a tag), idempotentHint=true suggests it can be safely retried, readOnlyHint=false confirms it modifies state, and openWorldHint=true hints that the object is not fully enumerable. The description and annotaions are consistent. Although the description does not elaborate further, the annotations carry the transparency burden effectively.

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 extremely concise at 6 words, which is efficient but borders on under-specification. Every word serves a purpose, but the sentence is structured as a fragment ('Remove a tag attachment from a video.'). It is front-loaded and readable, but could be slightly more complete (e.g., including the resource ID or context) without sacrificing brevity.

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 low complexity (2 required params, no enums, no nested objects) and the presence of an output schema and annotations, the description is minimally adequate. However, it does not specify what happens on success (e.g., returns void or confirmation), nor does it mention if the operation is reversible. The agent might benefit from knowing the response format or side effects, but the annotations partially compensate for this gap.

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 100%, meaning the schema already documents both parameters (tag and video) with descriptions. The tool description adds no extra meaning beyond the schema, and there are no enums or nested objects. Per the guidelines, when coverage is high (>80%), baseline is 3 even without additional param info.

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 the resource 'tag attachment from a video', which precisely differentiates this from sibling tools like edubase_post_video_tag (which adds a tag) and edubase_get_video_tag (which reads). The sibling list contains many tag-related tools for different entities (class_tag, exam_tag, etc.), so the explicit mention of 'video' and 'tag attachment' makes the purpose unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives. For example, the sibling tools include edubase_get_video_tags (list tags) and edubase_post_video_tag (add tag), but the description does not advise that this tool is for removal only, nor does it mention any prerequisites (e.g., the tag must already be attached). An agent would need to infer usage from the action name alone.

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

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

Annotations already indicate write operation and non-destructive behavior. The description adds the prerequisite of requesting a link in advance but does not disclose file size limits, overwrite behavior, or error handling. No contradiction with annotations.

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?

Single sentence that conveys the core purpose and one key prerequisite. Slightly awkward phrasing ('with a link requested from the API in advance') but overall efficient and front-loaded.

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?

The description explains input well but lacks any mention of output or return value. Without an output schema, the AI is left guessing what the tool returns. Adequate for a basic upload operation but missing completeness.

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 100%, so parameter descriptions already exist. The description adds no significant new meaning beyond the schema, only restating that source can be local file or URL.

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?

Description clearly states 'Upload a local file or a file from a URL to the EduBase temporary file storage', specifying the action and target. It also mentions the prerequisite of having a filebin URL, distinguishing it from other tools.

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?

Description implies that a filebin URL must be obtained beforehand but does not explicitly compare to sibling tools like edubase_post_filebin_upload. No 'when to use' or 'when not to use' guidance is provided.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only the ambiguous 'Get/check', which neither clarifies a return format nor reveals whether it checks existence or retrieves full data—so it does not meaningfully go beyond the annotations.

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 sentence is terse but under-specified. It does not contain enough content to be called appropriately structured; it is merely a placeholder-level phrase that does not convey necessary context.

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 large set of class-related sibling tools and no explanation of the resource, the description is far from complete. The presence of an output schema does not make up for the absence of any functional or context-defining text; an agent cannot understand what data is affected or what results to expect beyond the bare phrase 'Get/check class'.

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% and already documents the 'class' parameter as a 'class identification string'. The description adds no further meaning to this parameter, so the schema carries the full explanatory burden; the baseline of 3 applies.

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 says 'Get/check class' but does not define what 'class' refers to in this domain or what 'check' implies. It essentially restates the resource name, so an agent cannot distinguish it from sibling tools like edubase_get_class_assignments or edubase_get_classes.

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 information about when to use this tool, what context favors it over alternatives, or any preconditions or exclusions. An agent has no guidance on how to choose between this and its many class-related siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the scope that it lists 'ALL' assignments, implying no filtering, but does not disclose additional behavioral details such as pagination, ordering, or whether only active assignments are returned. Given the strong annotation coverage, the description's contribution is minimal but not contradictory.

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: 'List all assignments in a class.' It contains no unnecessary words, is front-loaded with the action, and is easy to parse. Every word contributes to clarifying the tool's purpose.

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 simple one-parameter read operation with an output schema present, this description is largely complete. It tells an agent exactly what the tool does, and the output schema can provide return value details. However, it does not cover edge cases or contextual information (e.g., whether archived or finished assignments are included), which slightly reduces completeness.

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: the single required parameter 'class' is described as 'class identification string'. The description adds no further semantic detail about the class parameter beyond the context of 'in a class'. Since schema coverage is complete, the baseline 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 action ('List all assignments') and the resource ('in a class'). This distinguishes it from sibling tools like get_class, get_class_members, and get_quiz_questions, which deal with different resources. The verb+resource pairing is specific and unambiguous.

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 instead of alternatives. It does not mention the prerequisite of having a valid class identifier, nor does it explain any distinguishing scenarios (e.g., retrieving all assignments vs. filtering by user). This leaves an agent to infer usage solely from the tool name and description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context (e.g., pagination behavior, what 'owned and managed' precisely includes) beyond the schema. It neither contradicts nor enriches the annotations.

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 sentence with no filler, front-loading the verb and resource. It earns its place by stating the core purpose economically, with zero wasted 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 existence of an output schema and comprehensive annotations, the description is adequate for a simple list operation. However, it omits clarification on the 'owned and managed' scope and does not differentiate from sibling getters, leaving some contextual ambiguity for an AI agent.

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 the schema fully documents all three parameters (page, limit, search). The description does not mention parameters at all, but with complete 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 uses a specific verb ('List') and resource ('classes') with a clear scope ('owned and managed'), distinguishing it from sibling tools like edubase_get_class (single class) or edubase_get_class_members (members of a class). It is unambiguous and immediately understandable.

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 such as edubase_get_class or edubase_get_user_classes. It does not mention any exclusions, prerequisites, or conditions that would help an agent decide between similar listing tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it is a safe read operation. The description adds minimal behavioral context beyond stating it lists 'all' members, but does not disclose details like pagination.

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 sentence with no extraneous words. It is front-loaded and efficient, clearly stating the tool's action.

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's simplicity (one parameter, read-only, with annotations) and the presence of an output schema, the description is adequate. It does not need to explain return values as the output schema covers that. However, a brief mention of what 'members' means could improve clarity.

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 100% with the parameter description 'class identification string'. The description does not add any new meaning beyond what is in the schema, so baseline score of 3 applies.

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 (List) and resource (members) with a clear scope (in a class). It clearly distinguishes from sibling tools like edubase_get_class (class details) and edubase_get_class_assignments.

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 related tools like edubase_post_class_members for adding members or edubase_get_class for class details.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by clarifying the exact operation is checking a specific permission for a specific user on a class. It does not contradict annotations and aligns well with the safe, read-only behavior implied.

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, clear sentence that efficiently conveys the tool's purpose. Every word is necessary, and it is front-loaded with the key action and resource. No unnecessary fluff.

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 presence of an output schema (which presumably describes the boolean result), the simple description is sufficient. The tool's purpose is straightforward: checking a permission. The context signals (100% schema coverage, annotations) support completeness.

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% with all three parameters (user, class, permission) described. The description adds no additional parameter detail beyond what the schema provides. The enum for permission (view/report/control/modify/grant/admin) is well-defined in the schema.

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 'Check if a user has permission on a class' uses a specific verb ('Check') and clearly identifies the resource ('user') and target ('class'). It directly mirrors the tool name and is distinct from siblings like edubase_post_class_permission (which sets permissions) and edubase_delete_class_permission (which removes them).

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 implies this tool is for checking existing permissions, not setting or deleting them. It differentiates clearly from sibling tools like edubase_post_class_permission and edubase_delete_class_permission by being a 'check' rather than a mutation. However, it does not explicitly state when NOT to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the agent knows this is a safe, read-only, idempotent check that may return 'unknown' results. The description adds the direct behavioral meaning ('check if attached'), which aligns well with and adds minimal value beyond annotations. No contradiction is present.

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 directly states the tool's purpose. Every word earns its place. There is no unnecessary elaboration or fluff.

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 low complexity (2 required params, boolean output likely, rich annotations), the description is mostly adequate. It does not explicitly state the return type (e.g., boolean or existence flag), but the presence of an output schema (not provided in input) likely fills that gap. The openWorldHint suggests it may return 'unknown' status, which the description doesn't mention but the annotation covers.

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 the schema already documents both parameters ('tag' and 'class' identification strings). The description does not add any additional meaning about parameter types, formats, constraints, or relationships beyond what the schema provides. Baseline 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 'Check if tag is attached to a class' clearly states the verb ('check'), the resource ('tag'), and the target context ('class'). It distinguishes itself from sibling tools like 'get_class_tags' (which lists tags) or 'post_class_tag' (which attaches). While clear on the check, it does not explicitly say it returns a boolean or existence status, which 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 implies usage for verification (checking existence of a tag-class association). However, it does not explicitly state when to use this over alternatives like 'get_class_tags' (for listing all tags on a class) or 'get_tag' (to get tag details). No when-not-to-use or prerequisite guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate that this is a safe read operation. The description adds that it lists 'all' attached tags, implying a full collection, but it does not provide additional behavioral context such as whether pagination is involved, whether tags are sorted, or potential authorization requirements. Given the annotations cover the safety profile, the description adds moderate value but not much beyond its literal statement.

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, front-loaded sentence with no fluff or repetition. It immediately states the action and resource, making it easy for the agent to parse and act on. The word count is minimal and every word carries meaning.

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 single parameter and the presence of an output schema (which likely specifies the return shape), the description is reasonably complete. It lacks usage guidance and does not address edge cases like empty classes or permission constraints, but those may be understood from the output schema and the API context. For a simple list operation, it covers the necessary information to invoke the tool correctly; however, a mention of whether the list is paginated or the expected output format would place it at a perfect 5. Overall it is good but not exhaustive.

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 covers the only parameter 'class' with a descriptive note ('class identification string'), providing 100% coverage. The description neither adds nor clarifies the parameter's syntax or format beyond what the schema states. Since the schema already documents the parameter meaning and the description does not add alternative valid values or usage nuances, this is at the baseline level.

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 'List all attached tags of a class' clearly states the action ('List') and the resource ('tags of a class'), making the tool's purpose unambiguous. It is distinct from other tag-related siblings such as edubase_get_tags (all tags) and edubase_get_class_tag (a single tag), though it doesn't explicitly name those alternatives. It differentiates through its wording and the schema requires a class identifier.

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 explicit guidance on when to use this tool versus alternatives. It does not mention conditions like 'use when you need all tags for a class' or exclude cases where the user should instead use edubase_get_tag or edubase_get_class_tag. An agent would need to rely on the tool name and schema to infer appropriate usage, whereas a short usage note (e.g., 'prefer this over get_tags when you need a class''s tag set') or mention of pagination would be helpful.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no behavioral context beyond what is structured. It does not mention return type (Boolean likely), what happens if permission is missing (false vs error), or performance implications. For a simple check tool, this is adequate but minimal—the description does not add value beyond existing annotations.

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 sentence that is concise but under-specified. It does not elaborate on edge cases or return format. While brevity is good, the description fails to use its space to add value beyond the schema and annotations, essentially repeating the title. It could include guidance on output format or hierarchical permission behavior.

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's simplicity (3 required params, no nested objects, an output schema likely exists), the description is minimally complete. It tells you what it does but not what it returns or how to interpret results (e.g., does permission check respect hierarchies? Is it exact match or inheritance?). The presence of an output schema reduces the burden, but the description still lacks context on permission semantics.

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 100% with clear descriptions for all three parameters. The description adds no extra param meaning, but the schema already fully specifies the string identifiers and enum values. With full coverage, baseline 3 is appropriate, and the description's lack of redundancy keeps it at 3. However, the schema's 'permission' enum is well-documented, so no deduction.

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 it checks permissions on a course for a user, which matches the name and title. It is distinct from sibling tools like edubase_get_class_permission, which likely checks class-level permissions. A sibling named edubase_post_course_permission exists for granting permissions, so this tool's purpose as a read-only check is well-differentiated.

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 implies this is the appropriate tool to verify course permissions, but it offers no explicit guidance on when to use this versus alternatives like edubase_get_class_permission or edubase_get_exam_permission. It does not mention that this is read-only or that it requires specific arguments. No usage exclusions or triggers are provided beyond the schema's required fields.

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

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

Annotations already supply readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds no additional behavioral context (e.g., output format, error behavior). Since annotations carry the burden effectively, a baseline score of 3 is appropriate.

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 directly states the tool's purpose. Every word earns its place; there is no fluff or repetition.

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's simplicity, full schema coverage, and the existence of an output schema, the description is largely complete. It could be slightly more explicit about the return type (e.g., 'returns a boolean'), but the output schema likely covers that. The description is adequate for an agent to use correctly.

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% (both 'course' and 'tag' have descriptions in the input schema). The description 'Check if tag is attached to a course' adds no extra semantic meaning beyond what the schema already provides. Baseline 3 is fair.

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 'Check if tag is attached to a course' uses a specific verb ('Check') and a clear resource ('tag attached to a course'). It effectively distinguishes this tool from siblings like 'edubase_get_course_tags' (list all tags), 'edubase_post_course_tag' (attach), and 'edubase_delete_course_tag' (detach) by indicating an existence check.

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 does not provide explicit guidance on when to use this tool versus alternatives. For example, it does not mention that this tool is for checking a single tag's existence, while 'edubase_get_course_tags' should be used to list all tags. No when-not-to-use or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false, so the safety profile is fully covered. The description adds no behavioral context beyond listing tags, which is acceptable for such a simple read-only tool.

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?

A single, efficient sentence with no redundant wording. It front-loads the core action (list) and the scope (attached tags of a course).

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 simple read-only listing tool with full annotations, an output schema, and one documented parameter, the description is sufficient. It lacks only minor details like return format, but the output schema likely covers that.

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% and the parameter 'course' is described as 'course identification string'. The description adds no further meaning about the parameter, so baseline 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 'List all attached tags of a course' uses a specific verb and resource, clearly distinguishing this plural listing tool from its singular sibling get_course_tag. The scope is unambiguous.

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 is clear: it lists tags attached to a specific course, which implies when to use it versus alternatives like get_course_tag (singular) or get_tags (global listing). However, it does not explicitly mention when not to use it or name alternatives.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond duplicating the title, such as the return type or side effects.

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?

A single, front-loaded sentence (9 words) effectively communicates the core action. Slightly more structure could improve clarity, but it is concise for a simple tool.

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 3 required parameters and an existing output schema, the description lacks contextual details like what the output signifies or typical usage scenarios. It is insufficient for an agent fully to understand when and how to invoke the tool.

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 100% with well-described parameters. The description adds no extra meaning, so baseline 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 verb 'Check' and the resource 'permission on an event', distinguishing it from sibling tools like edubase_delete_event_permission or edubase_get_event_tag. However, it does not elaborate on the specific permission levels or 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?

No guidance on when to use this tool vs. alternatives (e.g., delete or post). The description provides no exclusions or context about when not to use it.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds no new behavioral context beyond what the annotations convey, such as whether partial matches are possible or what happens on non-existent event/tag. It does not contradict annotations.

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 short sentence that is front-loaded with the key information. It has no wasted words, but could potentially include a tiny bit more context without becoming verbose.

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 simple nature of this check tool (2 required parameters, output schema present), the description is minimally sufficient. However, more details about return format or edge cases (e.g., boolean result vs error) would improve completeness, though the output schema may compensate.

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 the schema already documents both parameters ('tag identification string', 'event identification string'). The description does not add meaning beyond what the schema provides, placing it at the baseline of 3.

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 action ('check') and the resource ('tag attached to an event'). It distinguishes from sibling tools like edubase_post_event_tag (create) and edubase_delete_event_tag (delete), making the read-only nature of this tool obvious.

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 implies usage for verification but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use get_event_tags to list all tags vs this for checking a specific association). No exclusions or context about prerequisites are mentioned.

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