EduBase MCP Server

Official

by EduBase

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v1.1.5
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
View server inspector
This server provides 100 tools. View schema
No known security issues or vulnerabilities reported.
Report a security issue
This server has been verified by its author.
View related servers

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. While annotations indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false) that is not idempotent (idempotentHint=false), the description doesn't explain what happens when toggling the 'active' flag, error conditions, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is severely underspecified rather than appropriately concise. It fails to front-load critical information about the scope of updates (limited to activation status per the schema) that would help an agent determine tool applicability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a relatively simple mutation tool with only two parameters, the description is inadequate. It fails to acknowledge that updates appear limited to the 'active' status flag (based on schema inspection), doesn't reference the required integration identifier format, and provides no context on return values or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters 'integration' and 'active' are fully documented in the schema itself. The description mentions neither parameter, but since the schema already explains that 'active' enables/disables the integration, the description meets the baseline requirement without adding supplementary semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update integration' is tautological, essentially restating the tool name (edubase_patch_integration) without adding specificity. While it identifies the resource type, it fails to distinguish from siblings like edubase_post_integration or edubase_delete_integration, and doesn't clarify what aspects of an integration can be modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this patch operation versus creating a new integration (edubase_post_integration) or deleting one (edubase_delete_integration). No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context beyond these annotations—specifically, it does not explain what 'check' means (existence verification vs retrieval), error handling when a class is not found, or what data structure the output schema represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief (three words), the description wastes the agent's attention by introducing ambiguity with 'Get/check' rather than being precise. The slash conflates two potentially different operations without clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (reducing the need for return value description), the description inadequately addresses the tool's core ambiguity—whether it performs retrieval, existence checking, or both. For a tool with a single parameter, the description should clearly resolve this behavioral question.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('class identification string'), so the schema fully documents the single parameter. The description adds no additional semantic information about the parameter format or examples, warranting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check class' restates the tool name with minimal expansion. The slash creates ambiguity between retrieval and verification semantics, and it fails to distinguish this single-class lookup from the sibling edubase_get_classes (plural list) or other class-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus edubase_get_classes (list vs single record) or other class-related operations. No mention of prerequisites or error conditions for the 'check' functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond this. Critically, it fails to explain the idempotentHint=false annotation (meaning repeated calls may have cumulative effects), which is vital for a PATCH operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though only two words, this represents under-specification rather than effective conciseness. The sentence fails to earn its place by providing no information beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with numerous siblings (including GET, POST, DELETE variants), the description inadequately explains the update scope, return values, or error conditions. No output schema exists to compensate for these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'organization' parameter, the schema carries the full burden. The description adds no supplementary context about the identification string format or examples, warranting the baseline score for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update organization.' is tautological, essentially restating the tool name 'edubase_patch_organization' without clarifying the PATCH semantics (partial update) or distinguishing from sibling 'edubase_post_organization'. It fails to specify what aspects of an organization can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use PATCH vs the sibling POST endpoint, when partial updates are preferred over full updates, or prerequisites for invocation. The agent has no signal to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. While annotations correctly indicate readOnlyHint=false and destructiveHint=false, the description fails to explain the non-idempotent nature (idempotentHint=false is unusual for a PATCH operation), partial update semantics, or error conditions (e.g., webhook not found). No contradiction exists, but no value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is excessively brief to the point of underspecification. It is not 'concise' in the positive sense of information density, but rather incomplete. The single sentence fails to earn its place by providing actionable intelligence beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation operation affecting organizational webhooks, the description is inadequate. It omits context about the PATCH method's partial update nature, the specific 'active' toggle functionality visible in the schema, and the required identification strings. Given the idempotentHint=false annotation, the lack of explanation about side effects or repeated call behavior is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline score applies. The schema adequately documents all three parameters (organization, webhook, active). The description contributes no additional parameter semantics, but the schema carries the full burden successfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update organizational webhook' is a tautology that restates the tool name and title. While it uses a specific verb ('Update'), it fails to distinguish this PATCH operation from sibling tools like edubase_post_organization_webhook (create) or edubase_get_organization_webhook (retrieve), and does not specify what aspects of the webhook can be modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 (create vs. update), nor are prerequisites mentioned (e.g., requiring the webhook to exist, needing organization admin permissions). The description is silent on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations correctly identify this as destructive and idempotent, but the description adds no behavioral context beyond what the annotations provide. It fails to mention what happens to nested resources (members, courses, exams), whether deletion is permanent, or required authorization levels for such a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two words), which prevents bloat, but this brevity fails to earn its place by adding value. It is front-loaded but wastes the opportunity to provide necessary context for a destructive operation on a primary resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation on a top-level organizational entity with cascading implications, the description is inadequate. No output schema exists, yet the description does not indicate what successful deletion returns or whether partial deletion is possible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'organization' parameter is documented as 'organization identification string'), the description does not need to compensate for missing schema documentation. The description mentions no parameters, which is acceptable given the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove organization' is a tautology that restates the tool name (edubase_delete_organization). While it confirms the action and resource, it fails to distinguish this tool from siblings like edubase_delete_organization_members or edubase_delete_organization_tag, which is critical given the 40+ sibling deletion tools available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. Given the presence of numerous sibling tools for deleting organization sub-resources (members, permissions, tags, webhooks), the description should explicitly state this deletes the entire organization entity and suggest when to use the more granular deletion tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds only the word 'check', which vaguely implies existence validation but provides no details on failure modes, authentication requirements, or what constitutes a valid 'integration identification string' beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word description is maximally brief and front-loaded, but conciseness requires information density. The sentence earns minimal utility—it communicates barely more than the tool name itself. No structural issues, but under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and comprehensive annotations, the description remains insufficient for sibling differentiation in a complex API surface. It fails to clarify that this retrieves a specific integration by identifier versus listing all integrations, a critical distinction given the presence of both 'get_integration' and 'get_integrations' endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'integration' parameter ('integration identification string'), the baseline score applies. The description adds no parameter-specific context (e.g., expected format, examples, or whether this is a UUID vs slug), but the schema carries the load adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check integration' restates the tool name with minimal expansion. While it identifies the resource (integration), it fails to distinguish this single-item retrieval from the sibling 'edubase_get_integrations' (plural/list endpoint). The dual verbs 'Get/check' create ambiguity about whether this validates existence or retrieves data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'edubase_get_integrations' or 'edubase_get_integration_keys'. No mention of prerequisites, error conditions (e.g., if integration doesn't exist), or relationship to the POST/DELETE/PATCH integration siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent), but the description fails to clarify what 'check' means—whether it validates existence, returns different status codes, or is simply synonymous with 'get'. No behavioral context is added 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is brief but under-specified rather than efficiently concise. It lacks the necessary information density to be useful, though it contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich sibling ecosystem (including edubase_get_user_me which the schema references as preferred for 'me'), the description should clarify relationships and scope. It does not leverage the existing output schema to justify its brevity regarding return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and only one parameter, the baseline score applies. The parameter description in the schema adequately explains the 'user' string and special 'me' value, so the main description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check user' is tautological (restates the tool name) and ambiguous regarding the 'check' functionality. It fails to distinguish from siblings like edubase_get_user_me (current user) or edubase_get_users (list), leaving the scope unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. While the parameter schema mentions preferring /user:me for current user lookups, this critical usage context is absent from the main description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly mark this as destructive and idempotent, the description adds no context about what destruction entails (permanent removal, impact on active connections, or reversibility).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-word description is brief but constitutes under-specification rather than effective conciseness; the sentence fails to earn its place by adding no actionable information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a destructive operation with numerous similarly-named sibling tools. The description should clarify the distinction between deleting an integration entity versus deleting its sub-resources (permissions, tags).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with the 'integration' parameter documented as an 'integration identification string'. The description adds no further semantics, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove integration' merely restates the tool name (delete/remove synonym) without clarifying what type of integration is being removed or distinguishing from siblings like edubase_delete_integration_permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives such as edubase_delete_integration_tag or edubase_delete_integration_permission, nor any prerequisites for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the word 'check' which might imply existence verification, but does not clarify what 'checking' entails (boolean return vs. full object vs. error on missing), what happens if the exam ID is invalid, or any rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief (3 words), it is underspecified rather than appropriately concise. Given the large sibling toolset (80+ tools) and ambiguity of 'check', the description wastes no words but fails to front-load critical scoping information (single exam retrieval by ID).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values need not be described. However, the description omits critical context: that this retrieves a single specific exam versus listing (edubase_get_exams), and what differentiates 'getting' from 'checking'. For a tool with 100% schema coverage but many siblings, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'exam' parameter documented as 'exam identification string'. The description adds no parameter semantics, but the baseline score of 3 applies since the schema is fully self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get/check') and resource ('exam'), but remains vague about the 'check' semantics and fails to distinguish from sibling 'edubase_get_exams' (plural list) or sub-resource getters like 'edubase_get_exam_users'. It meets minimum viability but lacks specificity regarding scope (single entity retrieval vs. list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus the plural 'edubase_get_exams' or other exam-related endpoints. No prerequisites or error conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and retry behavior. The description adds the '/check' capability but does not explain what this means (existence validation, permissions check, or return format), leaving behavioral gaps despite the hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief (3 words), the description is inappropriately sized for the tool's context—too terse to explain the 'check' functionality or differentiate from 100+ siblings. It is front-loaded but under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, return values need not be described. However, the description leaves critical gaps: it does not clarify the dual 'get/check' behavior, distinguish from the plural list endpoint, or indicate what constitutes a valid 'organization identification string' beyond the schema's generic label.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string'), the schema fully documents the single parameter. The description adds no semantic clarification beyond the schema, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Get') and resource ('organization'), meeting basic clarity. However, the '/check' dual-purpose phrasing is ambiguous (validation vs. retrieval) and fails to distinguish from sibling 'edubase_get_organizations' (plural list vs. single entity retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like 'edubase_get_organizations' or 'edubase_post_organization'. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, establishing the safety profile. The description adds no behavioral context beyond these annotations—no explanation of whether this is a hard or soft delete, what happens to associated data (enrollments, submissions), 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two words), which is appropriate for a single-parameter operation, but lacks structural front-loading of critical differentiators needed to distinguish from sibling tools. It is concise but not strategically structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high density of similar sibling tools (edubase_delete_user_*, edubase_delete_*_members) and the destructive nature of the operation, the description is inadequate. It should clarify that this deletes the user account itself (not just associations) and explain data retention implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'user' parameter is documented as 'user identification string'), the schema carries the full burden. The description mentions no parameters, but baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete user.' is a tautology that restates the tool name (edubase_delete_user). While it identifies the resource, it fails to distinguish from numerous sibling tools like edubase_delete_user_classes, edubase_delete_user_login, and edubase_delete_user_organizations, which all 'delete user' related resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus the many sibling alternatives (e.g., when to delete the user entirely vs. removing them from classes or organizations). No prerequisites mentioned (e.g., whether the user must be deactivated first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description does not contradict annotations (correctly implying a read operation that aligns with readOnlyHint=true), it adds zero behavioral context beyond what annotations already provide. It does not disclose return format, what defines a 'group', caching behavior, or any side effects not captured in the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (3 words), which prevents verbosity, but the single sentence fails to earn its place by conveying minimal information. It is front-loaded but empty, representing under-specification rather than efficient information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 simple single-parameter input, the description meets minimum structural requirements. However, it is incomplete regarding the domain model: 'group' is a specific entity type in educational systems (distinct from classes, organizations, or roles), and the description should clarify this relationship given the numerous sibling tools operating on similar user-associated resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'user' parameter is documented as 'user identification string'), the description meets the baseline expectation. However, the description itself adds no semantic information about the parameter (e.g., expected format, examples, or whether it accepts email vs ID) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user's group.' is a tautology that restates the tool name (edubase_get_user_group) without adding specificity. It fails to distinguish this tool from siblings like edubase_get_user_classes, edubase_get_user_organizations, or edubase_get_user, leaving ambiguous what constitutes a 'group' in this educational context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_user_organizations or edubase_get_user_classes. There are no stated prerequisites, exclusions, or workflow context to help an agent determine applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=false and destructiveHint=false, the description adds no behavioral context about what fields can be updated (only 'active' per schema), side effects, or the non-idempotent nature declared in annotations (idempotentHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (2 words), which prevents verbosity, but it is too minimal to be considered well-structured or front-loaded with useful information. It wastes the opportunity to convey critical usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a user management operation with 2 parameters and no output schema, the description is incomplete. It fails to clarify the limited scope of updates possible (only the 'active' field) or how this relates to the broader user lifecycle management evident in the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents both parameters ('user identification string' and 'enable or disable user'). The description adds no parameter semantics, meeting the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update user' is a tautology that restates the tool name and title without distinguishing from siblings like edubase_post_user (create) or edubase_delete_user. It fails to clarify that this tool specifically performs partial updates (PATCH) rather than full replacements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this PATCH operation versus the POST (create) or DELETE alternatives. No mention of prerequisites, permissions, or that this is intended for toggling user status based on the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive, non-idempotent write operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description adds no behavioral context beyond this. It does not explain side effects, what happens to the class's previous owner/enrollments, or why the operation is non-idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single sentence is not verbose, it is inappropriately terse for the complexity of a transfer operation. The description is front-loaded with the verb but lacks the substance to be genuinely useful, failing the 'every sentence earns its place' standard due to under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a transfer operation with behavioral complexity (non-idempotent) and an output schema exists, the description is inadequate. It omits critical domain context such as permission requirements, the nature of the transfer relationship being created, and how it differs from membership operations in the sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('class identification string', 'user identification string'), the parameters are adequately documented in the schema itself. The description adds no additional semantic context (e.g., expected ID formats, whether the user must exist beforehand), meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer class to user' is extremely minimal and borders on tautology, essentially restating the tool name. While it identifies the action (transfer) and target resource (class), it fails to specify what 'transfer' entails (ownership change, enrollment, assignment?) or distinguish from similar sibling tools like edubase_post_user_classes or edubase_post_class_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., edubase_post_class_members for adding members), prerequisites for the transfer, or conditions under which the operation might fail. The description offers zero contextual guidance for an agent deciding between the numerous similar membership/transfer tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation, but the description adds no behavioral context beyond this. It does not explain what happens to existing branding on update, the effects of repeated calls, or expected 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at only four words. While not verbose, it is underspecified rather than efficiently concise—no sentences earn their place because none provide substantial guidance beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with 4 parameters performing write operations, the description is inadequate. It lacks information about return values, error conditions, the non-idempotent nature (per annotations), or interaction with existing branding configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully documented in the schema itself (image formats, color enum values, type options). The description adds no parameter-specific guidance, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure or update exam branding' is essentially a tautology that restates the tool name (post_exam_branding). While it identifies the resource, it fails to distinguish from siblings like edubase_delete_exam_branding or edubase_get_exam_branding, or clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives such as edubase_delete_exam_branding or edubase_get_exam_branding. No prerequisites (e.g., exam existence) or usage constraints are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. While annotations indicate this is a non-read-only, non-destructive operation, the description does not explain what happens to the previous assignee, whether the transfer is immediate, or what the output schema represents. With annotations covering the safety profile, the description offers minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at four words with no redundant content, earning points for lack of bloat. However, 'appropriately sized' is questionable given the complexity of transfer operations; the single sentence fails to earn its place due to underspecification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the existence of an output schema excuses the description from explaining return values, the description remains inadequate for a mutation tool. It fails to explain side effects, error conditions (e.g., integration already assigned), or the business logic of transferring integrations within the edubase domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('integration identification string', 'user identification string'), the schema adequately documents the parameters. The description adds no additional semantic information (e.g., whether these are UUIDs, emails, or usernames), meriting the baseline score for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer integration to user' is essentially a tautology that restates the tool name and annotation title. While it identifies the verb (transfer) and resource (integration), it fails to define what 'transfer' means in this context (ownership change? assignment? sharing?) and does not distinguish this tool from sibling transfer operations (class_transfer, course_transfer, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_patch_integration or edubase_post_integration_permission. It omits prerequisites (e.g., does the user need pre-existing permissions?) and fails to indicate whether this operation is reversible or idempotent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), but the description adds no behavioral context beyond these hints. It fails to explain what happens during the transfer, whether it triggers notifications, if it's reversible, or what the output schema represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The four-word description is certainly not verbose, but it is inappropriately terse for a tool with an output schema and behavioral complexity implied by the 'transfer' operation. It lacks front-loaded value beyond the label, though it contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (excusing return value documentation), the description inadequately covers the tool's semantics. It omits what 'transfer' entails, how it relates to the Edubase learning management workflow, and fails to leverage the presence of annotations to focus on domain-specific context that structured fields cannot provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('SCORM identification string' and 'user identification string'), the baseline score applies. The description adds no parameter-specific guidance (format examples, where to obtain IDs, validation rules), but the schema adequately documents the two required string parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer SCORM to user' is tautological, essentially restating the tool name (edubase_post_scorm_transfer). While it identifies the verb (transfer), resource (SCORM), and target (user), it fails to distinguish from numerous sibling transfer tools (class_transfer, course_transfer, exam_transfer, etc.) or explain what 'transfer' means in this educational context (enrollment? assignment? ownership change?).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. With many sibling 'transfer' operations available for different resource types (courses, classes, quizzes, etc.), the description offers no criteria for selecting this specific tool or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate destructiveHint=true and idempotentHint=true, the description adds minimal behavioral context. It does not clarify what 'archive' implies versus 'remove', whether the operation is recoverable, or what happens to associated data like exam results, certificates, or questions. The idempotent nature is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only three words ('Remove/archive exam.'), the description is excessively terse for a destructive operation with ambiguous semantics. The brevity creates uncertainty rather than clarity, failing to earn its place as adequate documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no output schema, the description should clarify the archive vs. delete semantics and data retention implications. The current description leaves critical behavioral questions unanswered, making it insufficient for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string'), the schema sufficiently documents the parameter. The description adds no additional parameter context, meeting the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (Remove/archive) and resource (exam), but the 'Remove/archive' phrasing creates ambiguity about whether this performs a hard delete or soft delete/archive. It fails to distinguish this tool from siblings like edubase_delete_exam_branding or edubase_delete_exam_users that delete specific exam components rather than the exam itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus related tools. Given the presence of sibling tools for deleting specific exam aspects (permissions, tags, users, branding), the description should clarify that this targets the exam entity itself, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false) and not idempotent (idempotentHint: false), but the description adds no context about these traits. It fails to explain what happens on duplicate calls, transfer failures, or side effects like notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at four words with no redundancy. While it could be argued it is under-specified rather than concise, it contains zero wasted words and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is inadequate for a mutation tool with business logic implications. It fails to define 'transfer' semantics (move vs. copy, ownership vs. access) or explain the non-idempotent behavior indicated in annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('video identification string', 'user identification string'), the schema sufficiently documents parameters. The description adds no additional semantic context, meeting the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Transfer') and target ('video to user'), meeting minimum viability. However, it fails to differentiate from sibling transfer tools (e.g., edubase_post_class_transfer) or clarify whether this changes ownership, grants access, or moves the resource between workspaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this versus edubase_post_video_permission, prerequisites (whether the user/video must exist), or if this is reversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly indicate this is a non-destructive write operation, the description fails to explain what actually happens during the transfer (e.g., whether the previous owner loses access, if this affects existing members, or what the idempotentHint: false implies for repeated calls).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (4 words), which avoids bloat, but it is under-specified rather than efficiently concise—every sentence must earn its place, and this single sentence merely restates the tool name without adding actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation operation involving organization ownership transfer, the description is inadequate. It omits critical context about side effects, authorization requirements, and the implications of the transfer, despite the existence of an output schema that could inform the agent of return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented as 'identification strings'. The description adds no further context about expected formats, valid ID patterns, or whether these refer to existing entities, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (transfer), resource (organization), and target (user), but 'transfer' is semantically ambiguous in this context—it does not clarify whether this changes ownership, administrative control, or membership, nor does it distinguish from sibling transfer tools like edubase_post_class_transfer or edubase_post_user_organizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., edubase_post_organization_members for adding users), nor any mention of prerequisites such as administrative permissions required to perform a transfer operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, establishing it is a safe write operation. However, the description adds no behavioral context about side effects, idempotency implications (annotation says false), or what happens if the tag is already assigned to another user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at four words. No filler content, but borders on under-specification. Front-loaded with the action verb, though the brevity limits utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive input schema annotations, the description meets minimum requirements for a simple two-parameter tool. However, for a 'transfer' operation (which often implies complex state changes), the description lacks necessary detail about the operation's semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('tag identification string', 'user identification string'), so the structured data fully documents parameters. The description adds no semantic detail beyond the schema, but does not need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action ('Transfer') and resources ('tag', 'user'), but lacks specificity about what 'transfer' entails (assignment vs. ownership change) and does not differentiate from sibling transfer tools like edubase_post_class_transfer or edubase_post_course_transfer beyond the resource name implied in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., edubase_post_class_tag), prerequisites (whether the user/tag must exist), or expected outcomes. The description is purely declarative with no operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, non-destructive, and idempotent properties. Description adds no context about the sensitive nature of returned secrets, security handling requirements, or whether this returns active vs. historical keys. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at four words with no wasted language. While concise, the single sentence is arguably too terse to provide meaningful operational guidance beyond restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and only one parameter, the description is inadequate for a credential-retrieval tool. Significant gaps remain regarding security implications of handling secrets and lifecycle context (retrieval vs. rotation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with the `integration` parameter documented as 'integration identification string'. Description adds no semantic details about parameter format or examples, meeting baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action (Get) and resource (integration keys/secrets) but lacks specificity about scope (requires specific integration ID) and does not differentiate from sibling `edubase_post_integration_keys` which likely handles key generation/rotation rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this retrieval endpoint versus the creation endpoint (`edubase_post_integration_keys`), nor any prerequisites for accessing sensitive credential data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly indicate this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false), the description adds no context about what 'transfer' actually does—whether it creates a copy, moves ownership, or establishes a student-teacher relationship. The non-idempotent nature (idempotentHint: false) is noted in annotations but unexplained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient with no redundant words, but it is arguably too terse for the complexity of a 'transfer' operation. It front-loads the action but leaves critical behavioral questions unanswered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (relieving the description of return value documentation), the description inadequately explains the transfer semantics. Given the destructiveHint is false, the agent needs to know what state changes occur—does the course change ownership, or is the user merely added? The description is insufficient for a mutating operation with non-idempotent behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters as identification strings. The description does not add format details, examples, or semantic constraints (e.g., whether the user ID refers to the recipient or current owner), earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (transfer) and targets (course, user), but 'transfer' is semantically ambiguous—it could imply ownership change, enrollment, or assignment. It fails to distinguish from sibling transfer tools (e.g., edubase_post_class_transfer, edubase_post_event_transfer) or clarify the specific relationship being established.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives like edubase_post_course_permission (which might grant access without transferring) or enrollment tools. No prerequisites (e.g., does the course need to be published? Does the user need specific permissions?) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds no behavioral context beyond these hints— it does not specify whether the transfer is reversible, if it triggers notifications, or what happens if the exam is already assigned to the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at four words with no redundancy. While it avoids waste, it is arguably underspecified rather than optimally concise—a single additional sentence clarifying the transfer mechanism would significantly improve utility without violating conciseness principles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple parameters (2 strings) and the presence of an output schema, the description is incomplete because it fails to define the domain-specific meaning of 'transfer.' For a tool with many sibling transfer operations (class, course, quiz, etc.), the description should clarify whether this assigns, enrolls, or changes ownership.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'exam' and 'user' parameters documented as identification strings in the input schema. The description adds no additional semantic meaning (e.g., expected ID formats, whether these are UUIDs or email addresses), warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb (transfer) and target resource (exam to user), but 'transfer' is ambiguous in an educational context—does it mean enroll the user in the exam, transfer ownership, or copy the exam to the user's workspace? It does not distinguish from sibling tools like `edubase_post_exam_users` or clarify the transfer directionality beyond the parameter names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as `edubase_post_exam_users` (which likely adds users to an exam) or `edubase_delete_exam_users`. No prerequisites, exclusions, or contextual triggers are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is a non-read-only, non-destructive write operation, but the description adds no behavioral context about side effects, idempotency (creates duplicate orgs if called twice), return values, or the implications of the domain parameter requiring special privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at three words with no wasted text. However, the brevity borders on under-specification; it is front-loaded but lacks the substantive content to be truly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation operation with 6 parameters and an output schema, the description is insufficient. It omits relationships to entities (members, webhooks, permissions), success behavior, and the privileged nature of certain operations mentioned in parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 6 parameters (name, description, domain, website, email, phone). The description adds no additional parameter context, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action ('Create') and resource ('organization') but lacks scope or differentiating context from siblings like edubase_post_user_organizations or edubase_post_organization_members. Minimal viable description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives (e.g., patch_organization for updates), prerequisites (e.g., admin rights), or the special privileges required for setting the domain field as noted in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations comprehensively cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds no behavioral context beyond this, but does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word description is maximally concise and front-loaded. While efficient, it borders on under-specification; however, no words are wasted or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, simple read operation), presence of an output schema, and comprehensive annotations, the description is minimally adequate. However, it lacks contextual guidance regarding sibling differentiation that would help an agent select this over edubase_get_user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'user' parameter ('user identification string'), the structured documentation is complete. The description adds no parameter semantics but meets the baseline given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user's name' is tautological, essentially restating the tool name (edubase_get_user_name). It fails to distinguish this tool from the sibling edubase_get_user (which likely returns a full user object including the name) or clarify what specific name format is returned (display name, full name, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 specialized getter versus the broader edubase_get_user, nor does it mention when to prefer this over edubase_get_user_me for the current authenticated user. No prerequisites or permission requirements are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint: false) that is non-destructive and non-idempotent, but the description fails to explain what 'transfer' entails (ownership reassignment, moving from another user, copying), leaving behavioral ambiguity despite the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at four words with no filler. While appropriately front-loaded, it borders on under-specification given the complete absence of behavioral details, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with complete schema coverage and an output schema present, the description is minimally viable but lacks explanatory depth regarding the transfer operation's business logic and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('event identification string', 'user identification string'), the schema fully documents parameters. The description mentions 'event' and 'user' but adds no additional semantic context (formats, constraints), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (transfer) and target resource (event to user), but is minimal and does not meaningfully differentiate from sibling transfer tools (edubase_post_class_transfer, edubase_post_course_transfer, etc.) beyond restating the resource type already present in the function name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternative transfer tools, prerequisites for the operation (e.g., does the user need to exist? does the event need to be unassigned?), or when transfers are permitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only and not destructive, but the description adds no operational context beyond this. Critical details missing: whether old keys are immediately invalidated, if there is a grace period, or whether this generates a new key pair or regenerates secrets in-place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at only three words with zero redundancy. Every word earns its place. However, 'appropriately sized' is debatable given the security-critical nature of the operation warrants more explanation, though the sentence structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (reducing the need to describe return values), the description is inadequate for a security-sensitive mutation. It omits side effects, authentication requirements, and operational impact that would help an agent decide if rotation is safe to perform.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'integration' parameter, the description meets the baseline. However, it adds no semantic value regarding the parameter (e.g., expected format, where to obtain the identification string, examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific technical verb 'Rotate' and identifies the resource 'integration keys/secrets', clearly indicating a credential regeneration operation. However, it fails to explicitly distinguish from sibling tools like 'edubase_get_integration_keys' (which retrieves keys) or 'edubase_patch_integration' (which updates settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., requiring admin privileges) or warnings about the impact of rotation on existing integrations. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false), the description adds no behavioral context beyond these hints. It fails to explain what 'transfer' entails (move vs. copy), side effects, or the nature of the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words. While it wastes no space, it is arguably underspecified for a state-changing operation. However, the sentence is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 well-documented input parameters, the description meets minimum requirements. However, for a mutation tool with non-idempotent hints, it lacks explanation of business logic, success/failure states, or what the operation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Quiz identification string', 'user identification string'), the schema fully documents the parameters. The description adds no additional semantic context (e.g., ID formats, lookup requirements), meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (Transfer) and target (Quiz to user), but 'Transfer' remains ambiguous without context—it could imply assignment, ownership change, or duplication. It does not differentiate from sibling tools like `edubase_post_quiz` (create) or `edubase_post_quiz_permission` (share access).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., assigning via permissions vs. transferring), prerequisites (whether the user must exist beforehand), or post-conditions. The agent must infer usage from the parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description relies entirely on annotations for behavioral disclosure (readOnlyHint=false, destructiveHint=false, idempotentHint=false). It adds no context about side effects, what constitutes a valid 'group code', or the implications of the non-idempotent hint—critical information given that 'Update' operations are typically idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only four words. While it wastes no space, it arguably errs toward under-specification rather than efficient information density. It meets the minimum threshold without redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and an output schema, the description meets baseline completeness by identifying the operation. However, it fails to address the non-idempotent nature of the operation (unusual for updates) or explain the output structure, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add semantic meaning beyond the schema (e.g., format examples for the group code or user identification string), but it does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (Update) and resource (user's group), but provides minimal specificity about the operation's scope or how it differs from sibling tools like `edubase_get_user_group` or `edubase_post_user`. It does not clarify whether this replaces an existing group or adds an additional group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites for invocation, or expected workflow. The existence of `edubase_get_user_group` suggests a read/write pair, but the description does not articulate this relationship or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description does not contradict the annotations (consistent with readOnlyHint=false), it adds no behavioral context beyond what the structured annotations already disclose. It fails to explain the idempotentHint=false status or what happens when the tool is invoked multiple times.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately concise and front-loaded with the core action. However, the extreme brevity limits utility, as additional context regarding sibling differentiation could be added without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% input schema coverage, presence of annotations declaring the non-destructive write nature, and existence of an output schema, the minimal description is technically adequate but leaves significant gaps regarding tool selection rationale in the context of numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage documenting all five parameters including validation constraints (character limits), the schema carries the full semantic burden. The description adds no parameter-specific guidance, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb ('Update') and resource ('user's name'), but fails to distinguish this tool from the sibling 'edubase_patch_user' which could also modify user attributes. It does not clarify why an agent should choose this specific endpoint over the general user patch endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_patch_user', nor does it mention prerequisites (e.g., user existence requirements) or constraints on name format beyond what the schema contains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context that this affects 'next requests,' indicating a session state change that persists beyond the single call—information not present in annotations. However, it omits critical behavioral details like session duration, audit logging implications, or whether the assumption affects all subsequent calls globally or only specific request types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no filler. However, it may be too terse for a security-sensitive authentication tool, omitting essential safety and operational context that would help an agent use this correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an impersonation/authentication tool that changes execution context for subsequent operations, the description is dangerously incomplete. It fails to mention the security implications, required privileges, how to terminate the assumption (via the delete sibling), or the scope of affected subsequent requests, despite having an output schema available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter semantics are adequately handled by the schema itself. The description adds no additional context about when the optional 'password' parameter is required versus the 'user' identification, or what constitutes a 'user secret,' meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action ('Assume user') and mentions the mechanism ('assume token'), but uses technical jargon without clarifying that this is an impersonation/sudo operation. It fails to distinguish from sibling 'edubase_delete_user_assume' which terminates the session, leaving ambiguity about whether this creates, updates, or uses an existing assumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus ending an assumption (edubase_delete_user_assume), nor on prerequisites such as administrative privileges typically required for user impersonation. The agent must infer usage from the method name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive=true and idempotent=true, but the description adds no behavioral context beyond this. It fails to disclose what exactly gets destroyed (configuration history vs. just future triggers), whether the operation is reversible, or that retries are safe due to idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at three words. No redundant or wasted text. However, the single sentence is arguably too brief for a destructive operation, though it efficiently conveys the core action without structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema, the description is insufficient. It lacks explanation of side effects (e.g., immediate termination of webhook deliveries), confirmation of whether the operation is permanent, or reference to the idempotent nature declared in annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear parameter descriptions ('organization identification string', 'webhook identification string'). The tool description itself does not mention parameters, but since schema coverage exceeds 80%, the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Remove' and resource 'organizational webhook' clearly indicating the action and target. However, it fails to distinguish from sibling tools like edubase_delete_organization (which deletes the entire organization) or differentiate from edubase_patch_organization_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as edubase_patch_organization_webhook (to disable/modify) or edubase_get_organization_webhook (to verify existence). No prerequisites or warnings about irreversibility are mentioned despite the destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds no behavioral context beyond these annotations—it doesn't mention pagination, what member attributes are returned, or whether the list is real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it is extremely minimal and could have utilized the space to provide usage context or behavioral details rather than just restating the tool name's meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 doesn't need to explain return values or safety properties. However, for a tool in a large ecosystem with 100+ siblings, the description lacks context about what constitutes a 'member' (e.g., students, teachers) and how this relates to other membership-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'class' parameter, the schema fully documents the input. The description mentions no parameters, but given the schema's completeness, this meets the baseline expectation without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and resource ('members in a class'), accurately reflecting the tool's function. However, it fails to differentiate from the sibling tool 'edubase_get_class', which likely retrieves class metadata rather than member lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_user_classes' (which might find classes for a user) or 'edubase_post_class_members' (which adds members). No prerequisites or contextual triggers are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description confirms it's a read operation ('Get') but adds no further behavioral context—such as what constitutes 'results' (scores, answers, completion status), error handling for missing users/exams, or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with no filler words. However, extreme brevity contributes to under-specification regarding sibling differentiation and result content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, existing output schema, and comprehensive annotations, the description meets minimum requirements. However, it fails to address the distinction between this tool and edubase_get_exam_results_raw, which is relevant given the sibling tool density.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters ('exam', 'user') described as 'identification string'. The description references both parameters implicitly but adds no semantic depth (e.g., whether these are UUIDs, email addresses, or internal IDs) beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('user results for a specific exam'), matching the tool name. It implicitly distinguishes from 'raw' results siblings by specifying 'user', though it could explicitly clarify the difference from edubase_get_exam_results_raw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like edubase_get_exam_results_raw or edubase_get_exam_certificates_user. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations adequately cover safety traits (readOnlyHint, destructiveHint, idempotentHint), the description adds no behavioral context beyond the basic action. It fails to disclose what constitutes a successful check, error conditions (e.g., if the integration doesn't exist), or the nature of the return value despite the tool being a read operation with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the verb ('Check'). While appropriately brief, it borders on under-specification; however, for conciseness specifically, it avoids redundancy and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure (three required strings, one enum), 100% schema coverage, and existence of an output schema, the description is minimally adequate. It does not need to exhaustively document return values, but it could have clarified the verification logic or parameter relationships (e.g., that all three are mandatory identifiers).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for all three parameters (integration, user, permission) and the enum fully documented in the schema, the baseline is established. The description contributes no additional semantics, constraints, or format details beyond what the structured schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Check') and the specific resource ('permission on an integration'), distinguishing it from sibling tools like 'edubase_get_integration' (which retrieves the integration itself) and the 'post'/'delete' permission variants. However, it stops short of clarifying what 'check' means in terms of return value (boolean vs. permission object).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when to verify permissions vs. modify them) or any prerequisites (such as requiring valid integration or user IDs). It relies entirely on the agent inferring usage from the tool name pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already disclose readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context—such as return value format (boolean vs. object), error handling when the quiz/user does not exist, or permission inheritance rules—beyond what the name and annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately brief and front-loaded with the core action. No extraneous words are present. However, it borders on tautology with the tool name, and one additional sentence describing the return value could improve utility without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and complete input schema, the description covers the primary purpose adequately. However, it omits discussion of the return value semantics (despite the existence of an output schema) and does not clarify the permission hierarchy relationships (e.g., whether 'admin' implies 'grant').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (quiz, user, and permission parameters all documented), the description serves as a high-level summary only. It does not add syntax details, validation rules, or usage examples beyond the schema definitions, warranting the baseline score for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 quiz' provides a specific verb (Check) and resource (quiz permission). It distinguishes from siblings like edubase_get_class_permission by specifying the 'quiz' resource. However, it does not explicitly differentiate from edubase_post_quiz_permission or edubase_delete_quiz_permission beyond the implicit contrast in verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_post_quiz_permission for granting permissions. It lacks prerequisites (e.g., 'use this before attempting modifications') or conditions that would help an agent select this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the 'check' nuance, suggesting verification capability, but does not clarify behavioral details like what happens if the tag doesn't exist or what data is returned (though output schema 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief ('Get/check tag.') with no wasted words. While underspecified, it is front-loaded and efficient, avoiding redundancy with the structured schema and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 (not shown in detail but indicated) and complete input schema coverage, the description doesn't need to explain return values or parameter formats. However, it lacks context on the 'check' functionality and tag resource semantics, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single 'tag' parameter ('tag identification string'). The description adds no parameter-specific guidance, but with complete schema coverage, it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get/check' and resource 'tag', indicating a read operation on a specific tag resource. However, it fails to differentiate from sibling 'edubase_get_tags' (plural) or clarify what 'check' means (verify existence vs. retrieve metadata). It is vague but not strictly tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_tags' (plural) for listing or 'edubase_get_tag_permission' for access control. No prerequisites, error conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no behavioral context beyond what annotations provide, such as return value semantics (boolean vs. object), cache behavior, or permission hierarchy implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it is minimal to the point of underutilizing the available space for additional context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, present annotations, and an output schema, the description serves as an adequate minimum viable summary. However, it lacks elaboration on permission semantics or result interpretation that would make it fully complete without requiring schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear parameter definitions ('tag identification string', etc.). The description provides no additional parameter guidance (e.g., permission level precedence or ID format examples), warranting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Check') and resource ('tag permission') with specific scope ('user'). It effectively distinguishes from sibling permission tools (e.g., edubase_post_tag_permission, edubase_get_class_permission) through the verb 'Check' and resource 'tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., checking class/course permissions) or how to interpret the result. The agent must infer usage solely from the tool name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly indicate this is not read-only and not destructive, the description fails to explain the idempotentHint=false behavior—specifically what happens if the tag is already attached (error, duplicate, or silent success). No additional context about rate limits, side effects, or authentication requirements is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words. While efficient and front-loaded, it borders on under-specification given the behavioral complexity implied by idempotentHint=false. No redundant or wasted language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema with complete field descriptions and the existence of an output schema, the description is minimally sufficient. However, it lacks important contextual details about idempotency and entity existence requirements that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('class identification string', 'tag identification string'), the schema fully documents the parameters. The description adds no supplemental parameter guidance, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and resource ('tag to a class'), clearly distinguishing it from sibling operations like 'delete_class_tag' or 'get_class_tags'. However, it doesn't explicitly clarify whether the tag must already exist or if this operation creates the tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites (e.g., whether the class and tag must exist beforehand) or idempotency constraints despite the annotation indicating idempotentHint=false.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint=false and destructiveHint=false, the description fails to explain the critical non-idempotent behavior (idempotentHint=false)—specifically whether duplicate calls error or create multiple entries. It also omits auth requirements and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with no redundant words. However, the extreme brevity contributes to under-specification, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and complete parameter documentation, the description is inadequate for an access control tool. It lacks essential context about the permission hierarchy (view < admin), error conditions, and idempotency behavior required for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully documented in the schema. The description adds no supplementary parameter context (e.g., expected format for 'user' IDs or behavior of the 'grant' permission level), meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Create'), resource ('permission'), and scope ('for a user on a course'), distinguishing it from siblings like edubase_post_class_permission. However, it could better clarify the distinction from the read-only variant edubase_get_course_permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_delete_course_permission for revocation), prerequisites (such as requiring admin rights), or when not to use it (e.g., if the permission already exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the write nature of the operation (consistent with 'readOnlyHint: false'), but adds no behavioral context beyond what annotations provide. It does not explain the implications of 'idempotentHint: false' (that repeated calls may behave differently) or describe the output structure despite the existence of an output schema. No information about side effects or failure modes is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The four-word description is extremely front-loaded with no redundant phrases or filler text. Every word directly contributes to understanding the core action. However, the extreme brevity leaves no room for behavioral context, making it efficient but insufficiently informative for a mutation operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema and annotations covering safety hints, the description omits key behavioral details such as error conditions (e.g., invalid course/tag IDs) and the non-idempotent nature of the operation. It adequately identifies the tool's purpose but fails to contextualize its use within the broader workflow of course tagging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for both parameters ('course identification string', 'tag identification string'), the schema fully documents the inputs. The description adds no semantic details, format examples, or validation rules beyond the schema definitions, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Attach') and resource ('tag to a course'), clearly identifying the operation's target. While it correctly scopes the action to courses, it does not explicitly differentiate from siblings like 'edubase_delete_course_tag' or 'edubase_post_course_permission' within the text itself. The description is clear but relies heavily on the tool name for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_course_tag' for removal. It fails to address the 'idempotentHint: false' annotation, omitting critical usage constraints like whether attaching an already-existing tag produces an error or succeeds silently. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare this is a non-destructive write (destructiveHint=false, readOnlyHint=false) and non-idempotent (idempotentHint=false), the description adds no behavioral context about what non-idempotent means in practice—such as whether duplicate assignments cause errors, are ignored, or create multiple entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely efficient and front-loaded with the action verb. While brief to the point of being minimal, it contains no redundant or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter structure with complete schema coverage and present annotations, the description is minimally adequate. However, it omits important behavioral details (error handling for invalid users, non-idempotent consequences) that would make it complete for safe agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string' and 'comma-separated list of user identification strings'), the schema carries the full semantic load. The description adds no additional parameter guidance (e.g., format constraints, max user count), warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Assign' with clear resources 'user(s)' and 'exam', making the purpose immediately understandable. However, it does not explicitly differentiate from the sibling tool 'edubase_delete_exam_users' or clarify when to use this versus other assignment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites (e.g., whether users must exist beforehand), or expected outcomes. It merely states the action without context for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly indicate readOnlyHint=false and idempotentHint=false (meaning multiple calls create multiple resources), the description adds no behavioral context beyond the verb 'Create'. It does not mention side effects, failure modes, or that the operation is non-idempotent despite this being critical information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, given the tool's complexity (5 parameters with conditional requirements), it may be overly terse rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description identifies the resource being created and leverages the comprehensive schema (100% coverage) and existing output schema. However, it fails to mention the LMS-specific parameter requirements or distinguish from update operations, leaving gaps in contextual completeness for an integration creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 implicitly maps to the 'type' parameter by mentioning 'API or LMS', but adds no further semantics about parameter relationships (e.g., that 'lti' and 'platform' are conditional on LMS type) or data formats beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and resource ('API or LMS integration'). It implicitly distinguishes from sibling operations like delete/get/patch through the verb choice, and from other POST operations (e.g., post_integration_keys) by specifying the core resource. However, it does not clarify when to use this versus patch_integration for updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., patch_integration for modifying existing integrations), nor does it mention prerequisites like checking for existing integrations. The conditional requirement of 'lti' and 'platform' parameters for LMS types is left entirely to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false) and not idempotent. The description adds no behavioral context about what happens if the user already has permissions, whether this replaces or appends, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at nine words. No filler or redundant text. However, it may be overly terse given the complexity of permission management with six distinct levels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a complex permission enum with six levels, the description provides no context about permission inheritance, the meaning of each permission level, or error conditions. Given this is a security-sensitive mutation tool, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter names and types are fully documented in the schema. The description adds no additional semantics about the permission hierarchy (view < report < control < modify < grant < admin) or integration identification formats, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the object (permission), and the scope (integration, user). It distinguishes from sibling delete/get permission tools via the verb 'Create', though it essentially restates the tool name in sentence form without adding scope constraints or behavioral nuances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus similar permission tools for other resources (classes, courses, exams), or prerequisites such as requiring admin access on the integration. No mention of failure modes like duplicate permission creation (given idempotentHint: false).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false) that is not idempotent, the description fails to disclose the increment functionality indicated in the schema (value parameter accepting '+prefix' syntax). It does not explain what happens on success, failure, or repeated invocations beyond the basic 'update' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single four-word sentence with no redundant or unnecessary text. However, it may be overly terse for a mutation operation with behavioral nuances (non-idempotent, increment support), leaving critical implementation details to be discovered only through the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a write operation with idempotentHint=false, an output schema, and special parameter behaviors (increment syntax), the description is insufficiently detailed. It fails to explain the metric recording behavior or provide context about the return value, relying entirely on structured fields for critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters are fully documented in the structured schema itself, including the special increment pattern for the value field. The description offers no additional semantic context beyond implying the parameters exist through the 'update' action, earning the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a custom metric' clearly identifies the action (update) and resource (custom metric) with a specific verb. It unambiguously describes the core operation. However, it lacks scope clarification regarding whether this appends metric values or modifies existing records, and offers no differentiation from sibling tools (though none appear to be metric-related).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites such as metric existence or required permissions. There is no information about error conditions, appropriate use cases, or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a non-idempotent write operation (readOnlyHint=false, idempotentHint=false), the description adds no behavioral context about side effects, failure modes, or the persistent nature of the created webhook versus transient triggers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficiently structured with no redundancy. However, given the tool's complexity (13 parameters with intricate authentication options), extreme brevity may underserve the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters supporting multiple authentication schemes (key, bearer, header, data) and three distinct trigger types, the 5-word description is insufficient. It omits critical context about the webhook's persistent nature and the complex authentication configuration required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage including detailed enum explanations for trigger_event and authentication flows, the schema carries the full burden of parameter documentation. The description adds no parameter guidance, which is acceptable given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with clear resource ('webhook') and scope ('organization'). However, it fails to distinguish from the sibling tool 'edubase_post_organization_webhook_trigger', which manually triggers webhooks rather than creating persistent configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this creation tool versus the patch variant for updates, or prerequisites like required permissions. The idempotentHint=false annotation suggests multiple calls create multiple webhooks, but the description doesn't warn about this behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While consistent with annotations (readOnlyHint: false), the description fails to disclose critical behavioral traits: it omits that the operation is non-idempotent (idempotentHint: false), doesn't clarify whether this adds to or replaces existing permissions, and doesn't mention error conditions (e.g., if permission already exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately brief and front-loaded, though it contains minor redundancy ('Create new' where 'new' is implied by 'Create').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter schema with full coverage and existing output schema, the description is minimally adequate, but gaps remain regarding idempotency behavior, permission inheritance/replacement logic, and semantic meaning of permission levels that would help agents handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 maps to the three parameters (quiz, user, permission) but adds no additional semantic context beyond what the schema already provides, such as explaining the hierarchy or practical differences between 'view' and 'admin' permission levels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Create' with resource 'permission' and scope 'for a user on a quiz', clearly distinguishing it from sibling tools like edubase_get_quiz_permission and edubase_delete_quiz_permission through the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when to update vs create), nor does it mention prerequisites such as whether the user or quiz must already exist before calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=false and destructiveHint=false (consistent with 'Attach'), the description adds no behavioral context beyond the annotations. Crucially, it ignores the idempotentHint=false annotation—failing to explain whether attaching an already-attached tag causes an error, is ignored, or creates duplicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The four-word description is extremely concise with zero redundancy. However, it borders on under-specification given the behavioral complexity (idempotency issues, prerequisites) that is left unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tagging operation with 100% schema coverage and an existing output schema, the description meets minimum viability. However, it lacks important contextual details—such as error conditions for missing entities or duplicate attachments—that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Quiz identification string', 'tag identification string'), the schema fully documents the parameters. The description adds no supplementary semantics (e.g., ID formats, lookup requirements), warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and clearly identifies the resource ('tag to a Quiz'). While it specifies the target resource type (Quiz), distinguishing it from similar sibling tools like edubase_post_class_tag, it misses the opportunity to clarify the nature of the attachment relationship or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 fails to mention prerequisites (e.g., whether the tag and quiz must exist beforehand), does not reference the inverse operation (edubase_delete_quiz_tag), and omits any warnings about duplicate attachments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond this. It fails to explain the idempotentHint=false implication (e.g., whether duplicate calls fail or create multiple entries), permission hierarchy (admin vs grant), or side effects of granting permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it may be overly terse given the complexity of permission management, leaving no room for behavioral caveats or usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive input schema annotations, the description adequately covers the basic contract. However, it lacks domain-specific context (permission inheritance, valid user/tag states) that would be expected for a security-related operation within the edubase ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear enum values for permission levels. The description does not add semantic context beyond the schema (e.g., explaining that 'grant' allows delegation while 'admin' implies full control), warranting the baseline score for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create), resource (permission), and scope (for a user on a tag). It effectively distinguishes this tool from sibling permission tools (e.g., edubase_post_class_permission, edubase_get_tag_permission) by specifying the target resource type ('tag') and the operation ('Create').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_delete_tag_permission or edubase_get_tag_permission. It does not mention prerequisites (e.g., user/tag existence) or conflict resolution behavior (e.g., what happens if the permission already exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a non-destructive write (readOnlyHint=false, destructiveHint=false), the description fails to mention behavioral traits like the non-idempotent nature (idempotentHint=false) implying duplicate username failures, or side effects such as automatic password generation and email/SMS notifications when the 'notify' parameter is used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the action verb front-loaded. However, extreme brevity comes at the cost of omitting helpful context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters with intricate behaviors like template-based creation, group assignment, and timezone configuration), a single sentence is insufficient. The description lacks mention of return values, error conditions (e.g., duplicate usernames), or the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all 18 parameters including constraints and defaults. The description adds no additional parameter semantics beyond the schema, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('EduBase user account'), clearly indicating it creates user accounts. However, it does not explicitly distinguish this from sibling tools like edubase_patch_user (updates) or relationship-management endpoints like edubase_post_user_classes, though the naming convention implies this is the primary creation endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_patch_user for updates, nor does it mention prerequisites like administrative permissions required to create accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond this. Critically, it fails to address the idempotentHint=false annotation—meaning the description does not clarify what happens if the permission already exists (duplicate creation vs. error vs. update), which is essential for correct agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it is minimally informative rather than richly concise—every sentence earns its place, but there is only one sentence where more context could have been provided without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 100% input schema coverage, the description adequately covers the basic contract. However, it lacks completeness regarding behavioral edge cases (non-idempotency handling, validation errors) that would help an agent handle failure modes or determine if the operation is an upsert vs. strict create.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all parameters (video ID, user ID, permission enum). The description adds no additional semantic context (e.g., permission hierarchy explanations or ID format details), meriting the baseline score for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Create) and target resource (permission for a user on a video), distinguishing it from sibling get/delete operations. However, it does not explicitly differentiate from similar 'post' siblings like edubase_post_video_tag, relying on the agent to infer the resource type from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when to update vs. create, or prerequisites like user/video existence). It lacks explicit when/when-not conditions or references to sibling tools like edubase_delete_video_permission for revocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare the operation as destructive and idempotent, the description adds no behavioral context beyond the basic action. It does not clarify what happens if the specified permission doesn't exist, whether the user loses all exam access or just this specific level, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action verb and conveys the essential operation without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of detailed annotations (destructive/idempotent hints) and complete input schema coverage, the description meets minimum viability. However, for a destructive permission operation, it lacks contextual details about side effects or permission hierarchy that would help an agent understand the full impact of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully documented in the schema itself ('exam identification string', 'user identification string', permission enum values). The description adds no supplementary semantics, syntax examples, or format details beyond the schema definitions, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('user permission from an exam') that clearly identifies the scope. It distinguishes from siblings like 'edubase_delete_exam' (which deletes the exam itself) and 'edubase_delete_exam_users' (which removes users entirely) by explicitly targeting 'permission'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_exam_users' (which likely removes all user access) or 'edubase_post_exam_permission' (which grants permissions). No prerequisites, error conditions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint: true matches 'Revoke'), confirming the irreversible nature of the action. However, it adds minimal behavioral context beyond the annotations—missing details on immediate effect (session termination), whether revocation is permanent, or security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient at three words with no filler. The single sentence is front-loaded and direct. However, for a destructive operation, this brevity verges on underspecification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a destructive tool (destructiveHint: true) with no output schema. The description omits what happens to active sessions, whether the revocation is immediate, and what an 'assume token' represents in this system—critical context given the technical specificity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'token' parameter is documented as 'assume token'), the description correctly relies on the schema. However, it fails to add usage context for the parameter, such as where to obtain the token or its expected format, earning the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Revoke) and resource (assume token) that aligns with the tool name. It clearly distinguishes this from sibling tools like edubase_delete_user (which deletes users) and edubase_post_user_assume (which likely creates the token), though it assumes familiarity with the 'assume token' concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the name implies this ends an impersonation session started by edubase_post_user_assume, the description fails to state this explicitly or mention prerequisites like needing an active assume token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly declare readOnlyHint=true and idempotentHint=true, the description adds no behavioral context beyond these structured fields. It fails to disclose pagination behavior, error handling (e.g., invalid class ID), or rate limiting considerations that would help an agent understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at seven words with no redundant or wasted text. It is front-loaded with the action and resource, making it scannable, though this brevity comes at the cost of informational depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 (covering return values) and fully documented single parameter, the description meets minimum viability for a list operation. However, clear gaps remain regarding scope boundaries (what constitutes an 'assignment' in this domain) and filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'class' parameter is documented as 'class identification string' in the schema), the baseline score applies. The description itself adds no parameter semantics, examples, or format guidance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List) and resource (assignments in a class), distinguishing it from siblings like edubase_get_class (which gets class metadata) and edubase_get_class_members (which gets users). However, it does not clarify the scope of 'assignments' (e.g., whether exams or quizzes are included) or temporal filtering (active vs. archived).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites such as needing the class identifier beforehand. There are no exclusions or conditional usage notes provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare the operation is read-only, idempotent, and non-destructive, the description adds no behavioral context beyond what is implied by the name. It fails to disclose what constitutes a positive vs negative result (e.g., boolean return, empty object, or 404 error) or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It is front-loaded with the action verb and contains zero extraneous words, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter input, comprehensive annotations covering safety/idempotency, and the existence of an output schema, the description is minimally adequate. However, it lacks guidance on interpreting results or differentiating from the plural 'get' sibling, leaving gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('integration identification string', 'tag identification string'), the description is not required to compensate. However, it adds no semantic clarification, examples, or format constraints beyond the schema definitions, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies the resources ('tag', 'integration'), clearly conveying the tool verifies attachment status. However, it does not distinguish from the sibling tool 'edubase_get_integration_tags' (plural), which likely lists all tags rather than checking a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_integration_tags' (to list all tags) or 'edubase_post_integration_tag' (to attach a new tag). There are no prerequisites or exclusion criteria stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint and idempotentHint, the description adds domain context about hierarchy position but creates confusion by stating 'To get question details, use the question export function'. This implies the tool has limited data access without clarifying what it actually returns, and omits error behaviors or caching characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-sentence structure efficiently delivers domain context and alternative tool guidance without excessive verbosity. Each sentence serves a distinct purpose: defining the operation, providing hierarchy context, and redirecting for detailed exports, though the third sentence introduces ambiguity regarding the tool's actual return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive parameter documentation, the description adequately covers domain context by explaining the question's role in the hierarchy. However, the uncertainty about whether this tool returns full question data versus basic existence checks, combined with no mention of pagination or rate limits, leaves gaps for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the 'id' parameter fully described as an 'external unique question identifier', establishing a solid baseline. The description provides no additional parameter context, examples, or format specifications beyond what the schema already supplies, meeting but not exceeding expectations for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Check' which conflicts with the tool name 'get_question', creating ambiguity about whether this retrieves full data or validates existence. While it provides useful domain context that questions are the 'lowest level in the EduBase hierarchy' and 'building blocks for Quiz sets', it fails to clearly distinguish this tool from siblings like edubase_get_question_id or edubase_get_questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly redirects users to the 'question export function' for obtaining question details, providing a clear alternative for a specific use case. However, it fails to specify when to use this tool versus similar retrieval tools like edubase_get_questions (plural) or edubase_get_question_id, leaving gaps in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations fully cover safety properties (readOnlyHint, destructiveHint, idempotentHint), but the description adds no behavioral context beyond the basic operation. It fails to disclose error handling (what happens if the identification string doesn't match?), lookup semantics (exact vs. fuzzy matching), or the format of the returned external identifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's purpose. There is no redundancy or unnecessary elaboration; every word serves a functional role in describing the input-output relationship.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 complete annotations, the description adequately covers the tool's basic contract. However, for a mapping/lookup tool, it omits important context about the identifier domain (what kind of strings are valid inputs) that would help an agent predict successful usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mirrors the schema's 'question identification string' phrase without adding clarifying examples, format specifications, or validation constraints. It neither adds value nor leaves gaps, meeting the minimum threshold for a well-documented single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get) and resource (external unique question identifier), distinguishing it from siblings like edubase_get_question (which likely returns full question objects). However, it lacks clarity on what constitutes a 'question identification string' (e.g., format or examples), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_get_question or edubase_post_question_id. While the read-only nature is clear, there is no discussion of prerequisites, error conditions (e.g., string not found), or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description aligns with these safety properties via 'Get/check' but adds no further behavioral context (e.g., whether this validates tokens, caching behavior, or rate limits) beyond what structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only three words, the description is maximally concise and front-loaded. However, it borders on under-specification; while efficient, it lacks the explanatory weight to fully justify its existence beyond the tool name and annotation title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of input parameters and the presence of an output schema, the description need not detail return values. However, it lacks contextual completeness regarding the authentication scope or session requirements that define the 'current' user identity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline applies. The description correctly implies no inputs are required to identify the target user (implied to be derived from authentication context), which matches the empty input schema without contradiction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Get/check') and identifies the target resource ('current user'), satisfying basic clarity. However, it fails to distinguish this tool from siblings like 'edubase_get_user' or 'edubase_get_users', leaving ambiguity regarding when to use the 'me' variant versus retrieving users by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative user retrieval methods, nor are prerequisites mentioned (such as authentication context required to define the 'current' user).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false) that is not idempotent. The description adds the context that this creates a 'new' resource and specifies the 'AI' nature (aligning with the default 'type' parameter), but doesn't disclose error conditions, validation rules, or whether the summary overwrites existing ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it is minimal to the point of being underspecified for a write operation with multiple optional metadata parameters. It effectively front-loads the core action but lacks supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 6 parameters (including specific LLM tracking fields), the description is insufficient. It fails to explain the significance of the AI-specific parameters ('llm', 'model'), the HTML formatting capability mentioned in the schema, or the lack of output schema. The annotations provide safety context, but the description doesn't complete the behavioral picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents all 6 parameters including the LLM metadata fields ('llm', 'model'). The description adds no parameter-specific guidance, but the high schema coverage meets the baseline expectation without requiring compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('AI exam summary'), clearly distinguishing it from sibling tools like 'edubase_post_exam' (which creates the exam itself) by specifying the 'summary' sub-resource. However, it doesn't clarify what an exam summary is used for (e.g., student-facing, administrative) or its relationship to the exam entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives, prerequisites (e.g., whether the exam must exist first), or when not to use it. Given the presence of many sibling 'post' tools, explicit guidance would help prevent confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations establish readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond this. It fails to explain the non-idempotent nature (idempotentHint=false) of the operation—specifically what happens if the tag is already attached—or describe the return value, despite having an output schema available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only four words. Every word earns its place by conveying the essential action and target resources without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter structure, complete schema coverage, presence of an output schema, and comprehensive annotations covering safety hints, the description is minimally sufficient. However, it lacks explanation of the non-idempotent behavior and return structure that would make it fully complete for agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('integration identification string', 'tag identification string'), the parameters are adequately documented in the schema. The description implies the relationship between parameters but does not add syntax details, constraints, or examples beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') with clear resources ('tag', 'integration'), accurately reflecting the operation. However, it does not explicitly differentiate from sibling tools like edubase_delete_integration_tag or edubase_get_integration_tags, which would help the agent select the correct tool in a family of tag-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when to attach vs. detach), nor does it mention prerequisites such as whether the integration or tag must exist beforehand. It states only what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description aligns with the non-destructive write operation indicated by annotations (readOnlyHint=false, destructiveHint=false), it adds no context about the behavioral implications of idempotentHint=false—specifically, what happens if the tag is already attached to the video (error, duplicate entry, or silent success). The description carries minimal behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with no redundant words. Every word earns its place by stating the core action and target resource immediately. It is appropriately front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter association tool with an output schema present, the description is minimally sufficient. However, it lacks explanation of the non-idempotent behavior (which could cause duplicates or errors on re-execution) and does not clarify error conditions or return values, leaving gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter meanings ('video identification string', 'tag identification string') are already documented in the structured schema. The description adds no additional semantic context, syntax examples, or clarifications about the identification string format, earning the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and clear resources ('tag', 'video'), establishing the tool's function as creating an association between a tag and a video. It implicitly distinguishes from sibling tools like 'edubase_delete_video_tag' and 'edubase_get_video_tags' through the action verb, though it could explicitly mention this is an 'add' or 'create' operation for absolute clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_video_tags' or 'edubase_delete_video_tag'. It does not mention prerequisites (e.g., whether the video and tag must already exist) or when this operation should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, establishing the safety profile. The description confirms the destructive nature ('Remove') but adds no further behavioral context about side effects, error conditions (e.g., if the permission doesn't exist), or prerequisites beyond what structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is appropriately sized and front-loaded with the action and target. It contains no wasted words, though its brevity leaves little room for critical context that would elevate it to a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 meets minimum viability by identifying the core action. However, gaps remain regarding the relationship between this action and member removal, as well as the implications of the idempotent behavior in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all three parameters (class, user, permission) including the enum values. The description maps to these parameters but adds no additional semantic details, syntax guidance, or explanations of the permission levels beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 class'). However, it does not explicitly differentiate from siblings like 'edubase_delete_class_members' (which removes the user entirely) or explain the distinction between removing a permission versus removing a member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 fails to clarify, for example, that this removes a specific permission level while keeping the user in the class, whereas 'edubase_delete_class_members' would remove the user completely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While consistent with annotations (destructiveHint=true implies the removal is permanent), the description adds no behavioral context beyond what the name and annotations provide. It does not clarify what 'branding' encompasses (logos, colors, themes), whether the exam reverts to default branding, or error conditions if the exam lacks custom branding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words with no wasted language. However, given the destructive nature of the operation, it is too minimal to provide necessary context without relying entirely on the annotations and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation, the description covers the basic intent but leaves gaps regarding the operation's effects (e.g., return value confirmation, side effects on exam appearance). Without an output schema, the description should ideally indicate what success looks like or whether the operation is idempotent (though annotations cover the latter).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string'), the schema adequately documents the single parameter. The description implies the 'exam' parameter refers to the target exam but adds no additional semantic details (e.g., format expectations, examples) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' with a clear resource 'branding from an exam'. It effectively distinguishes this tool from siblings like edubase_delete_exam (which deletes the entire exam) and edubase_delete_exam_tag/permission/users by specifying the exact attribute being targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_post_exam_branding (to update/set branding) or edubase_get_exam_branding (to check current branding). It lacks prerequisites, such as whether the exam must exist or if branding must be present before removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds no additional behavioral context (such as whether removed users' exam attempts/results are preserved, or if this triggers notifications), but does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded and contains no redundant or wasteful text. However, it is minimal to the point of being under-specified for a destructive operation, lacking any secondary sentences to clarify behavior or implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and 100% schema coverage, the description is minimally adequate. However, for a destructive tool affecting exam enrollments, it omits important context about what 'remove' entails (unenrollment vs. data deletion) and lacks output information, though no output schema exists to require such documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents both 'exam' and 'users' parameters. The description adds no additional parameter semantics (e.g., examples of ID formats or constraints on the comma-separated list), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Remove' and identifies the resource 'user(s) from an exam', making the basic purpose clear. However, it does not explicitly distinguish this from sibling operations like edubase_delete_exam (which deletes the exam entity) or edubase_delete_exam_permission (which removes permissions rather than users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_post_exam_users to add users), no prerequisites (e.g., whether users must be currently enrolled), and no warnings about irreversibility despite the destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint: true, idempotentHint: true) by using the verb 'Remove', confirming the destructive nature. However, it adds minimal behavioral context beyond the annotations—such as whether removed users lose access immediately, if they are notified, or whether the operation affects their other organization memberships.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of six words with no redundancy. While appropriately front-loaded with the action verb, it borders on underspecified given the destructive nature and lack of output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter deletion tool with robust annotations covering safety profiles, the description is minimally adequate. However, it lacks information about the return value (success indication), error conditions (e.g., if users aren't members), or whether the removal is reversible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string' and 'comma-separated list of user identification strings'), the schema fully documents the parameters. The description adds no additional semantic information about parameter formats or constraints, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Remove user(s) from an organization') that accurately describes the operation. However, it does not explicitly differentiate from similar tools like 'edubase_delete_user_organizations' (which likely removes a user from multiple organizations) or 'edubase_delete_organization' (which deletes the org itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_user' (which likely deletes the user entirely) or 'edubase_delete_user_organizations'. It also omits prerequisites such as administrative permissions or the impact on user's historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description confirms the removal action but adds no additional behavioral context (e.g., what happens if the permission doesn't exist, cascade effects, or return value details). No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero redundancy. While extremely brief, every word serves a purpose. However, the brevity leaves no room for qualifying important destructive behavior details beyond the verb 'Remove'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, comprehensive annotations (destructive, idempotent), and complete parameter documentation, the description is minimally sufficient. However, it fails to leverage the description field to clarify idempotent behavior or explain the permission hierarchy (view/admin/etc).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for 'tag', 'user', and 'permission' parameters. The description itself mentions no parameters, but with complete schema documentation, this meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Remove) with clear resource (user permission) and scope (from a tag). It distinguishes from siblings like edubase_delete_class_permission by specifying 'tag'. However, it assumes familiarity with the Edubase tag entity without elaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives (e.g., edubase_post_tag_permission to add permissions), prerequisites (whether the user/tag must exist), or consequences of removing permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, establishing the mutation safety profile. The description confirms the destructive action (remove) but adds no behavioral context beyond annotations, such as whether removal affects historical data or what occurs if the user is not enrolled in a specified class.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The four-word sentence is appropriately brief and front-loaded with the core action. While it wastes no space, it is arguably underspecified given the availability of sibling tools and the destructive nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter input schema with complete field descriptions and comprehensive annotations, the minimal description is technically sufficient for invocation. However, it lacks completeness regarding error handling, partial success scenarios, or the fact that classes must be specified as comma-separated values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (parameters documented as 'user identification string' and 'comma-separated list of class identification strings'), the description meets baseline expectations without needing to repeat parameter semantics, though it adds no supplementary context about ID formats or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove user from class(es)' clearly identifies the verb (remove) and resources (user, class), satisfying the basic requirement. However, it fails to distinguish from the sibling tool edubase_delete_class_members, which likely performs a similar operation from the class-centric perspective rather than user-centric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_delete_class_members for bulk removal from a single class, or edubase_post_user_classes for adding users), nor does it mention prerequisites such as user existence or enrollment status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context by specifying the scope ('owned and managed') which implies a permission-based filter, but does not elaborate on return format or pagination limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (4 words) with no redundant content. While efficient, it borders on under-specification given the lack of usage guidance; however, there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive annotations, the description adequately covers the essential scope constraint ('owned and managed'). However, it lacks completeness in guiding tool selection among the numerous class-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents all three parameters (search, limit, page). The description adds no additional parameter semantics, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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') and clarifies scope to 'owned and managed' classes. However, it does not explicitly differentiate from the singular sibling 'edubase_get_class' or explain when to use the list versus get operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_get_class' (singular) or 'edubase_get_class_members'. There is no mention of pagination behavior beyond the schema's 'not used in search mode' note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true, destructiveHint=false) by using the verb 'Check'. However, it adds minimal behavioral context beyond the annotations—omitting details about the return format (boolean vs. object), error conditions for missing users/courses, or the idempotent nature of the check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficient with no wasted words. However, it is borderline too terse for optimal agent decision-making; one additional sentence covering return value semantics or usage context would improve utility without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter structure, 100% schema coverage, existing output schema, and comprehensive annotations, the description is minimally adequate. However, it lacks guidance on interpreting results or handling the six permission levels, leaving minor gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters (course, user, permission) are fully documented in the JSON schema itself. The description adds no additional parameter semantics, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('course permission'), clearly distinguishing it from sibling tools targeting classes or events. However, it does not explicitly differentiate from the corresponding modification tools (edubase_post_course_permission, edubase_delete_course_permission) or clarify whether it retrieves permission details or performs a boolean verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like retrieving full course details, nor does it explain the permission hierarchy (e.g., whether 'admin' implies 'view'). No prerequisites or error handling scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly mark this as read-only, non-destructive, and idempotent. The description does not contradict these annotations and adds minimal context with the word 'attached,' but fails to elaborate on return format, pagination, or error conditions that might be relevant beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, it borders on being too terse given the existence of similar sibling tools that could benefit from differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with complete annotations and an output schema, the description covers the essential purpose. However, it misses the opportunity to clarify the scope (all tags vs. single tag) or provide context about what constitutes an 'attached' tag in this system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'course' parameter ('course identification string'), the baseline score is appropriate. The description does not mention parameters, but the schema is self-documenting enough that no additional clarification is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and resource ('attached tags of a course'), matching the tool's name. However, it does not explicitly differentiate from the sibling tool 'edubase_get_course_tag' (singular), which could confuse the agent about whether to retrieve one tag or all tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the singular 'get_course_tag'), nor does it mention prerequisites or constraints for the 'course' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true, destructiveHint=false) but adds no behavioral context beyond them. It does not disclose what the branding configuration contains (e.g., colors, logos, themes), error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words with no redundancy or filler. However, it is arguably too terse, leaving room for additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter read operation, presence of an output schema, and comprehensive safety annotations, the description is minimally adequate. However, it fails to explain what constitutes 'branding configuration' or provide any domain-specific context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string'), the baseline is 3. The description does not mention the parameter or add semantic context (e.g., expected format, examples) beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('exam branding configuration'), matching the tool name. It minimally distinguishes from sibling 'edubase_get_exam' by specifying 'branding configuration' rather than just 'exam', though it does not elaborate on what branding entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_post_exam_branding' (which likely sets branding) or 'edubase_get_exam' (which gets general exam data). No prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint: true) by using the verb 'List' and implies the operation is non-destructive. It adds the scope qualifier 'all' to indicate no filtering is available, matching the single-parameter schema. However, it omits details about pagination limits, error handling for invalid exam IDs, or the specific user roles included in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, front-loaded with the action verb, and contains no redundant phrasing. However, it borders on underspecification given the potential ambiguity of 'users' in an educational context; one additional clarifying clause would improve utility without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive annotations covering safety profiles, the description adequately indicates the tool's basic function. However, for a tool with siblings handling similar resources (delete_exam_users, post_exam_users), the description should clarify whether this returns enrolled candidates, administrators, or all associated personnel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter 'exam' is already documented as an 'exam identification string'. The description implies this parameter by referencing 'an exam' but adds no additional semantic information such as format examples (UUID vs. slug), validation rules, or whether the exam must be active.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('List') and resource ('users on an exam'), distinguishing it from siblings like 'edubase_delete_exam_users' and 'edubase_get_exam_results_user' through verb choice and scope. However, it lacks explicit differentiation from similar read operations and doesn't clarify what constitutes a 'user' (e.g., candidates vs. proctors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_exam_results_user' (which retrieves results rather than user lists) or 'edubase_get_exam' (which retrieves exam metadata). No prerequisites, permissions, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (read-only, non-destructive) but adds minimal behavioral context beyond them. It specifies 'all members' suggesting comprehensive listing, but omits details about pagination, permission errors, or whether results include nested sub-organizations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely concise and front-loaded with the verb. While efficient, it borders on under-specification given the lack of usage context, though it avoids redundancy with structured metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, comprehensive annotations, and a single parameter with full schema coverage, the description provides minimally sufficient context. However, it lacks guidance on edge cases (empty organizations, access denied) that would complete the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string'), the baseline is 3. The description references 'organization' but does not augment the schema with format details, examples, or semantics (e.g., whether it accepts UUIDs, slugs, or names).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') with specific resource ('members') and scope ('in an organization'), matching the tool name. It implicitly distinguishes from sibling 'get_class_members' via the organization scope, though it does not explicitly differentiate from reverse-lookup tools like 'get_user_organizations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., 'get_user_organizations' for finding a user's affiliations instead of an organization's roster), nor does it mention prerequisites like organization visibility permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint: true) by using 'Get,' confirming it's a safe read operation. It adds minimal context about organizational scoping ('configured in organization'), but fails to clarify what 'check' entails, what data is returned (though output schema exists), or whether it verifies webhook health/status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. However, the 'Get/check' construction is slightly awkward and creates ambiguity about whether this is a retrieval or validation operation, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no nesting) and the presence of an output schema and comprehensive annotations, the description is nearly sufficient. It could be improved by explicitly stating it retrieves webhook configuration details, but it meets the minimum viable threshold for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already defines 'organization' and 'webhook' as identification strings. The description mentions these concepts but adds no semantic value regarding format (e.g., UUID vs slug), constraints, or examples beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the core action ('Get/check') and resource ('webhook configured in organization'), distinguishing it from destructive siblings like edubase_delete_organization_webhook. However, 'check' is ambiguous—it could imply validation/testing rather than retrieval—and it doesn't clarify whether this retrieves details or merely verifies existence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_post_organization_webhook (create), edubase_patch_organization_webhook (update), or edubase_post_organization_webhook_trigger (test). It doesn't indicate prerequisites like needing the webhook ID beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable scope context ('owned and managed') not present in annotations, indicating this returns personal/managed questions rather than all system questions. However, it omits behavioral details like pagination limits or whether results are cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is front-loaded with the action verb and contains no redundant or wasteful text. While appropriately brief given the rich annotations and schema, it is arguably too minimal—bordering on under-specification—when considering the large sibling toolset that requires disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, presence of an output schema, and comprehensive annotations, the description provides minimum viable context for invocation. However, it lacks completeness regarding sibling differentiation and the specific semantics of 'owned and managed' versus other visibility scopes, leaving gaps that could cause selection errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all three parameters (search, limit, page). The description adds no supplemental parameter semantics (e.g., search syntax details, maximum limits), warranting the baseline score of 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with clear resource ('Quiz questions') and scope ('owned and managed'), distinguishing it from destructive siblings. However, it does not explicitly differentiate from 'edubase_get_quiz_questions' (which likely fetches questions for a specific quiz), potentially causing confusion about which list operation to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_question' (singular) or 'edubase_get_quiz_questions'. It also fails to clarify the interaction between search mode and pagination, despite the schema parameter hint that 'page' is 'not used in search mode!'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing the safety profile. The description adds no further behavioral context (e.g., whether results include multiple attempts, time spent, or partial credit) beyond what the output schema likely provides. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and contains no filler. Given the rich structured metadata (complete annotations, full schema coverage, output schema present), this brevity is appropriate, though slightly more context on the results payload could justify the tool's existence versus alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read operation with two well-documented parameters and existing output schema, the description is sufficient. The presence of annotations covering safety and idempotency reduces the burden on the description text, though explicit differentiation from 'play' results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Quiz set identification string', 'user identification string'), the schema fully documents parameter semantics. The description adds no additional parameter guidance (e.g., format expectations for IDs), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (Get), resource (user results), and scope (specific Quiz set) clearly. It implicitly distinguishes from sibling 'edubase_get_quiz_results_play' by specifying 'user' results, but does not explicitly clarify the difference between these aggregation methods or when to prefer one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance provided on when to use this tool versus siblings like 'edubase_get_quiz_results_play' (which likely retrieves session-level results) or 'edubase_get_exam_results_user'. There are no prerequisites, filters, or contextual triggers mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds valuable scope context ('owned and managed') indicating a permission-based filter, but doesn't clarify pagination behavior or the mutual exclusivity of search vs pagination modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with the core action. While not wasteful, it is arguably too terse given the tool's behavioral complexity (search vs pagination modes) and the crowded sibling namespace that requires differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a standard list operation with an output schema present (so return values need not be described). However, given the presence of singular 'get_tag' siblings and the special interaction between search/page parameters, the description should explicitly clarify this returns a collection/list versus a single entity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for all three parameters (search, limit, page), the schema carries the full load. The description mentions no parameters and adds no semantic clarification beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('tags') with ownership scope ('owned and managed'). However, it doesn't explicitly distinguish this listing tool from the singular sibling 'edubase_get_tag' which likely retrieves a specific tag by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'edubase_get_tag' (singular) or tag-specific permission tools. The critical schema note that 'page' is 'not used in search mode' is buried in the schema rather than highlighted in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond confirming this retrieves 'attached' tags. It does not clarify error handling (e.g., invalid video ID) or return format details, though these may be in the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action verb. However, extreme brevity leaves room for additional context (like sibling differentiation) without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, 100% schema coverage, existing output schema, and comprehensive annotations, the description provides sufficient context. The existence of 'edubase_get_video_tag' (singular) suggests a naming convention, though explicit clarification would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('video identification string'), the schema fully documents the single required parameter. The description adds no supplementary parameter details (such as format expectations or examples), meriting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('attached tags of a video'), including the scope word 'all' which helps distinguish from the singular sibling tool 'edubase_get_video_tag'. However, it lacks explicit differentiation explaining when to use this plural version versus the singular variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_video_tag' for specific tags), nor does it mention prerequisites like needing a valid video ID or what happens if the video has no tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint: false, destructiveHint: false), so the description does not need to carry that burden. However, it fails to clarify behavioral specifics implied by idempotentHint: false, such as whether duplicate calls fail silently, throw errors, or create duplicate permissions. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action verb. However, it may be overly terse given the lack of usage guidelines and behavioral transparency, leaving room for one additional clarifying sentence without violating conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 complete input schema documentation, the description does not need to explain return values or parameter details. However, for a permission creation tool with idempotentHint: false, the omission of conflict behavior and prerequisites leaves the description minimally viable rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('class identification string', 'user identification string', and the permission enum values), the structured schema fully documents the parameters. The description adds no semantic information beyond what the schema provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource ('permission for a user on a class'). It implicitly distinguishes from sibling tools like edubase_get_class_permission or edubase_post_course_permission through the combination of action and resource type, though it does not explicitly mention alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 similar tools like edubase_post_class_members or edubase_post_classes_members. It lacks prerequisites (e.g., whether the user must already exist) and does not explain failure modes or idempotency behavior despite the idempotentHint: false annotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=false, indicating this is a non-idempotent write operation. The description doesn't explain what happens on duplicate calls (errors vs. duplicates) or other behavioral nuances, but it doesn't contradict the annotations either. With annotations covering safety profile, this is baseline adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at three words with no redundancy. However, given the complexity signaled by idempotentHint=false and the existence of an output schema, the description could benefit from one additional sentence explaining non-idempotent behavior without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple association tool given the comprehensive schema coverage and existing output schema (which handles return documentation). However, it fails to address the implications of idempotentHint=false—specifically whether attaching an already-attached tag errors silently, throws an exception, or creates duplicate associations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'event' and 'tag' parameters documented as identification strings. The description mentions both parameters implicitly ('Attach tag to an event') but adds no semantic depth beyond the schema, such as ID format examples or whether the tag must pre-exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') with clear resource ('tag') and target ('event'), distinguishing it from sibling tools like edubase_post_class_tag or edubase_post_course_tag. However, it lacks domain context explaining what 'tag' means in the Edubase system (e.g., metadata label vs. category).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like edubase_get_event_tags (retrieval) or edubase_delete_event_tag (removal). No mention of prerequisites such as whether the event and tag must exist beforehand, or error handling scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint: false) that is non-destructive (destructiveHint: false) and non-idempotent (idempotentHint: false), suggesting multiple calls may create duplicates or errors. The description confirms the attachment action but does not elaborate on idempotency behavior, error conditions for non-existent exams/tags, or what the output schema contains. It adds minimal behavioral context beyond what structured 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single four-word sentence that immediately states the tool's purpose without extraneous information or filler. While efficiently structured and front-loaded, it may be overly terse given the lack of guidance on usage patterns and error states. The sentence earns its place, but additional qualifying details would improve agent decision-making without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, comprehensive annotations, and presence of an output schema, the description provides the minimum viable context for a straightforward tagging operation. However, it omits important contextual details such as the non-idempotent nature of the operation (hinted by annotations) and whether attaching an already-attached tag produces an error or succeeds silently. For a mutation tool, additional behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both required parameters ('exam identification string' and 'tag identification string'), clearly defining their purpose. The description does not add additional semantic context such as expected ID formats, whether these are UUIDs or human-readable slugs, or validation rules. With complete schema coverage, the description meets the baseline expectation without adding supplementary parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Attach' with the resource 'tag to an exam', clearly indicating the core function of creating a tag relationship. While the action is clear, it does not explicitly differentiate from sibling tools like `edubase_delete_exam_tag` or clarify whether this creates new tags or only attaches existing ones. The scope is implied but not explicitly bounded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_exam_tags` for retrieval or `edubase_delete_exam_tag` for removal. There are no stated prerequisites, such as whether the tag or exam must exist beforehand, nor any warnings about duplicate attachments. The agent must infer appropriate usage solely from the verb 'Attach' and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, establishing the write-but-safe nature. The description adds the critical context that storage is 'temporary,' implying expiration, but fails to elaborate on duration, link lifecycle, or the non-idempotent behavior (annotations show idempotentHint=false) that each call generates distinct links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is front-loaded with the action verb and contains no redundant words. However, it prioritizes brevity over completeness, leaving room for additional sentences covering usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 (not shown but indicated), the description correctly omits return value details. However, for a file upload workflow tool, it inadequately explains the conceptual model—specifically what 'temporary' means (duration, auto-deletion), how the returned link is consumed, and the relationship between link generation and actual file upload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters are fully documented in the structured schema. The description adds no semantic color beyond the schema (e.g., it doesn't explain that 'type' determines validation rules or acceptable formats for the subsequent upload), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action (Generate upload link) and resource (temporary file storage), providing specific verb-resource pairing. However, it does not explicitly differentiate from siblings like 'edubase_filebin' (likely retrieval) or 'edubase_delete_filebin_upload' in the text itself, relying on naming conventions rather than descriptive guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it explain the workflow (e.g., that this must be called before uploading files to obtain the endpoint). The 'force' parameter's behavioral implications (invalidating previous links) are left entirely to the schema without conceptual explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=false and destructiveHint=false, the description adds no behavioral context beyond this. It fails to explain the idempotentHint=false implication (what happens if permission already exists?), side effects, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, front-loaded with the action verb. No redundant information, though extremely minimal to the point of omitting useful context about the permission model.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation given the comprehensive schema and existing output schema, but lacks explanation of the six permission levels' hierarchy, whether this appends or replaces permissions, and relationships to sibling permission tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents all three parameters (organization, user, permission). The description adds no additional parameter semantics (e.g., permission hierarchy explanation), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with clear resource ('permission') and scope ('for a user on an organization'). It effectively distinguishes from sibling tools like edubase_post_class_permission or edubase_post_course_permission by explicitly targeting 'organization'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like edubase_get_organization_permission or edubase_delete_organization_permission. No mention of prerequisites (e.g., user/organization existence) or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false) and not idempotent (idempotentHint=false). The description confirms the write nature via 'Attach' but fails to explain the non-idempotent behavior (e.g., whether duplicate calls error or succeed) or if the tag must pre-exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words with no redundancy. However, given the presence of an output schema and idempotency considerations, it is slightly too minimal to earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the core function for a simple two-parameter tagging operation where an output schema exists. However, it lacks explanation of behavioral edge cases (duplicate attachments, missing resources) that would help an agent handle errors or confirm success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string', 'tag identification string'), the schema fully documents parameters. The description adds no additional semantic context regarding parameter format, valid values, or relationships, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and clearly identifies the resource (tag to organization), distinguishing it from sibling tools like 'edubase_delete_organization_tag' or 'edubase_post_class_tag'. However, it does not explicitly clarify when to use this versus retrieving tags or mention that it creates an association.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when the tag or organization must already exist), nor does it mention prerequisites, error conditions, or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds that this 'sets' an identifier but fails to explain idempotentHint=false (what happens if the ID already exists?) or whether this overwrites existing external IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately front-loaded with the verb 'Set'. It is slightly wordy ('for question identified by a question identification string' is redundant), but generally efficient without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with good schema coverage, the description meets minimum viability but lacks context expected for an identifier-mapping operation: validation rules, conflict resolution behavior, and the relationship to the corresponding GET endpoint (edubase_get_question_id).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents both parameters ('question identification string' and 'external unique question identifier'). The description repeats these concepts but adds no additional semantic context such as ID format constraints, uniqueness requirements, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target ('external unique question identifier'), using specific verbs and resources. However, it does not explicitly distinguish this from sibling tools like 'edubase_post_question' (which creates questions) or clarify that this operates on existing questions only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_question_id', nor does it mention prerequisites such as the question needing to exist beforehand. No exclusions or error conditions are documented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description confirms the domain-specific action (removing user-course permissions) but does not add behavioral details like what happens if the permission doesn't exist or side effects on course access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with zero redundancy. The action verb is front-loaded, and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, complete annotations (destructive, idempotent hints), and the presence of an output schema, the description provides the minimum necessary semantic glue. However, it does not compensate for any gaps or add richness regarding the deletion behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all three parameters (course, user, permission) including the enum values. The description provides semantic context mapping these to the sentence structure [Remove] a [permission] from a [course] for a [user], but adds no additional syntax rules or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 course'), distinguishing it from siblings targeting classes, events, or exams. However, it does not explicitly differentiate from related operations like adding permissions (edubase_post_course_permission) or specify scope constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites (e.g., verifying the permission exists), or expected error conditions. It merely states the action without context for selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, covering the safety profile. The description adds value by clarifying the dual-scope capability ('and/or') indicating it handles both persistent files and temporary links, which is not explicit in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It is appropriately front-loaded with the action verb and contains zero extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (destructive, idempotent hints) and simple single-parameter schema, the description is minimally adequate. However, for a destructive operation, it could benefit from mentioning the relationship to 'edubase_post_filebin_upload' or clarifying whether deletion is permanent vs. recoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameter 'id' is fully documented in the schema itself ('external unique filebin identifier...'). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 specific resources affected ('uploaded file and/or temporary file upload link'), distinguishing it from sibling delete operations that target classes, exams, or users. However, it doesn't explicitly reference 'Filebin' (the domain system name), relying on the tool name to provide that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites such as needing to obtain the 'id' from 'edubase_post_filebin_upload' or 'edubase_filebin'. It also doesn't warn about permanent deletion implications despite the destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is destructive (destructiveHint=true) and idempotent (idempotentHint=true). The description adds value by specifying that a 'tag attachment' is the target of deletion, implying the underlying integration and tag objects persist. However, it does not mention side effects, cascade behavior, or confirmation requirements beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence (7 words) that front-loads the action. No filler or redundant text is present, appropriate for a simple two-parameter deletion operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive annotations (destructive/idempotent hints), the description provides sufficient context for tool selection. However, it misses the opportunity to clarify that this operation only affects the relationship and that both entities remain available for future attachment, which would be valuable given the destructive annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('integration identification string', 'tag identification string'), the schema adequately documents parameters. The description provides no additional parameter semantics, so it meets the baseline of 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('tag attachment from an integration'), distinguishing it from the sibling 'edubase_delete_integration' which deletes the entire integration. However, it could explicitly clarify that this removes the association rather than deleting the tag resource itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'edubase_post_integration_tag' (to add tags) or 'edubase_get_integration_tags' (to verify current attachments). No prerequisites or workflow context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint=true is consistent with 'Remove'), but adds minimal context beyond the structured fields. It does not mention the idempotent nature of the operation (covered by annotations), error conditions (e.g., if permission doesn't exist), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is perfectly concise and front-loaded with the action verb. There is no redundant or extraneous information; every word serves to clarify the tool's specific purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations covering behavioral traits and an output schema (mentioned in context signals), the description meets minimum viability but does not enrich the context with domain-specific details like permission level hierarchies or the specific meaning of 'grant' versus 'admin' permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters are fully documented in the schema itself. The description does not add semantic details beyond the schema (e.g., example ID formats or permission hierarchy implications), warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Remove), resource (user permission), and scope (organization), distinguishing it from siblings like edubase_delete_organization (which deletes the entity itself) and edubase_delete_organization_members (which removes membership). However, it does not clarify the distinction between removing a specific permission level versus revoking all access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_permission for adding/updating), nor does it mention prerequisites such as requiring administrative privileges or the target user being an organization member.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly declare destructiveHint=true and idempotentHint=true, the description adds no behavioral context beyond what annotations provide. Critically, for a destructive operation, it fails to clarify whether 'remove' means unlinking questions from the quiz (keeping the questions in the system) or permanently deleting the question entities—a crucial distinction given the sibling tool 'edubase_delete_question'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action verb and fits the complexity of the tool perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter destructive operation with no output schema, the description covers the basic operation but lacks completeness regarding the return value, error conditions (e.g., what happens if the question isn't in the group), and confirmation of the idempotent nature. Given the simple schema, this is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all three parameters including the comma-separated format for 'questions' and the optional nature of 'group'. The description does not need to add significant parameter semantics, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Remove) and target resource (question(s) from a Quiz set). It distinguishes from 'edubase_delete_quiz' by specifying the operation targets contents within the quiz rather than the quiz itself. However, it does not explicitly differentiate from 'edubase_delete_question', leaving ambiguity about whether this deletes the underlying question entity or merely removes its association with the quiz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'or one of its question group' provides implicit guidance on when to use the optional 'group' parameter. However, there is no explicit guidance on when to use this tool versus 'edubase_delete_question' or 'edubase_post_quiz_questions', nor are there prerequisites stated (e.g., requiring the quiz to exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds minimal behavioral context ('previously generated' implies the link must exist), but does not explain the immediate effect (invalidation), side effects (logged out users?), or reversibility despite the sensitive security nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero redundancy. Every word earns its place—'previously generated' establishes the required state, 'login link' specifies the exact resource, and 'Delete' states the action. Appropriately front-loaded for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety hints and schema covering parameters, the description provides the minimum viable context. However, for a destructive authentication operation, it lacks explanation of what 'delete' means functionally (immediate invalidation vs. scheduled cleanup) and whether this affects other user sessions or links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear definitions ('user identification string', 'generated login link to be invalidated'). The description does not add parameter-specific semantics, but with complete schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and resource (previously generated login link), distinguishing it from siblings like edubase_delete_user that operate on the user account itself. However, it misses the opportunity to explicitly clarify that this invalidates an authentication credential rather than removing the user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives (e.g., edubase_delete_user for full account removal), nor prerequisites such as requiring the link to exist or whether this affects currently active sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 confirms the destructive nature through the verb 'Remove' but adds no additional behavioral context beyond the annotations—such as whether the user account itself is preserved, what happens to the user's content within the organizations, or the specific nature of the 'removal' (access revocation vs. record deletion). No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at four words with zero redundancy. It is front-loaded with the action verb 'Remove' and immediately identifies the target resource. Every word earns its place; there is no filler or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with two simple parameters and good annotations, the description covers the basic action but lacks completeness regarding side effects (e.g., impact on user's classes or content within those organizations, whether the operation is reversible). Without an output schema, the description could note typical success/failure modes, though this is less critical for a DELETE-like operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('user identification string' and 'comma-separated list of organization identification strings'), the schema fully documents parameter semantics. The description references 'user' and 'organization(s)' which maps to the parameters but adds no additional semantic value such as format examples, ID syntax requirements, or constraints. This meets the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove user from organization(s)' clearly states the specific action (remove) and scope (user from organizations). It aligns with the parameter structure (user + organizations) and distinguishes from siblings like edubase_delete_user (deletes the user entirely) and edubase_delete_organization (deletes the org itself). However, it does not explicitly differentiate from edubase_delete_organization_members, which likely operates from the organization perspective rather than the user perspective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_delete_organization_members or edubase_post_user_organizations (for transferring users). It also omits prerequisites (e.g., whether the user must exist, what happens if they're not currently a member) despite the idempotentHint annotation suggesting safe retry behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable semantic clarification that it removes the 'attachment' (relationship) rather than the tag entity itself, but does not describe idempotent behavior (e.g., what happens if the tag is not attached) or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. The most critical information (action and resource) is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, output schema, and simple 2-parameter structure, the description is minimally adequate. However, it lacks usage guidance and behavioral details (error handling, side effects) that would make it fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('video identification string', 'tag identification string'), the schema carries the full load. The description adds no parameter-specific semantics, syntax guidance, or examples beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Remove) and resource (tag attachment) and scope (from a video). It implicitly distinguishes from sibling 'edubase_delete_video_permission' by specifying 'tag' rather than 'permission', though it does not explicitly contrast with POST/GET variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_video_tag' to attach tags), nor does it mention prerequisites such as whether the video or tag must exist beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing the safety profile. The description confirms the 'check' behavior but adds no further context about return value semantics, error conditions (e.g., invalid event IDs), or permission hierarchy implications beyond what the structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with no redundant or wasted words. It is appropriately front-loaded with the core action and resource, suitable for a tool with simple, well-defined semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 100% schema coverage, rich annotations, and an output schema exists, the description meets minimum viability but remains sparse. It does not clarify the permission hierarchy (e.g., whether 'admin' implies 'view') or explain that the output schema likely contains a boolean or status result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (event, user, permission) fully documented in the input schema including the permission enum values. The description adds no supplementary parameter guidance, earning the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (check) and resource (event permission) with specific scope (user). However, it does not explicitly differentiate from sibling tools like `edubase_get_event_tag` or distinguish this read operation from `edubase_post_event_permission` in the text itself, relying on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it specify prerequisites (e.g., whether the user/event must exist first) or what to do based on the check result. It lacks explicit 'when to use' or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to cover safety. It adds valuable behavioral context with '(the latest)', indicating that only the most recent certificate is returned if multiple exist. However, it does not describe what happens when no certificate exists (error vs. null) or the format of the returned certificate details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every element serves a purpose: the action (Get), the behavioral qualifier ((the latest)), the resource (certificate details), and the required parameters (specific exam and user).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations covering safety/idempotency, the description adequately covers the basic use case. However, for a certificate lookup tool, it should ideally mention error handling (e.g., 'returns 404 if no certificate exists') or explicitly contrast with the download endpoint to prevent incorrect tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string', 'user identification string'), the schema already documents the parameters adequately. The description references these parameters implicitly ('specific exam and user') but does not add semantic meaning beyond what the schema provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), resource (certificate details), and scope (specific exam and user). It distinguishes itself from siblings like edubase_get_exam_results_user by specifying 'certificate' rather than 'results', and from edubase_get_exam_users by requiring both exam and user parameters. However, it does not explicitly contrast with edubase_post_exam_certificates_user_download (which likely downloads the file vs. returning details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_post_exam_certificates_user_download (download vs. metadata retrieval) or edubase_get_exam_results_user. It also does not mention prerequisites, such as whether the user must have completed the exam or if certificates must be enabled for the exam.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations comprehensively cover the safety profile (readOnly, non-destructive, idempotent), so the description does not need to repeat these traits. However, the description adds no additional behavioral context about return values, error states (e.g., invalid organization/user), or the boolean nature of the permission check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with no redundant words or filler content. It immediately communicates the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete input schema annotations, presence of an output schema, and comprehensive MCP annotations covering behavioral traits, the description provides sufficient context for tool selection despite its brevity. However, it could improve by clarifying that it checks for a specific permission level rather than permission in general.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters are fully documented in the schema itself (organization ID, user ID, and permission enum). The description adds no supplementary parameter guidance, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks permission status for a user on an organization, using specific verb 'Check' and resource 'organization'. It distinguishes from sibling tools like edubase_get_organization (which retrieves the organization itself) and edubase_post_organization_permission (which modifies permissions). However, it lacks specificity about checking a specific permission level versus general permission status, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_organization (which may include permission data in its response) or the permission modification tools (post/delete). There are no explicit preconditions, error conditions, or workflow suggestions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description doesn't need to cover safety traits. The description aligns with these annotations. It adds scoping context ('attached tags') but doesn't describe return format, pagination, or error behavior (e.g., quiz not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, verb-first structure, zero redundancy. Every word serves a purpose. Appropriate length for a simple list operation with strong schema/annotation support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read operation with output schema available and strong annotation coverage. However, misses opportunity to clarify the plural vs singular distinction from 'edubase_get_quiz_tag' sibling, which would prevent selection errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'quiz' parameter documented as 'Quiz identification string'. The description implies this parameter identifies which quiz to query, but doesn't add semantic details about the identifier format or where to obtain it. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear resource 'attached tags of a Quiz'. The word 'all' implicitly distinguishes from sibling tool 'edubase_get_quiz_tag' (singular), though it doesn't explicitly clarify when to use the plural vs singular variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'edubase_get_quiz_tag' (singular) or 'edubase_get_tag'. No mention of prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by specifying the filtering behavior ('managed, non-generated' users) not captured in annotations. However, it omits details about pagination behavior, result ordering, or the relationship between search mode and page parameter (though the schema notes this).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at four words. Every word serves a purpose: 'List' declares the action, 'managed' and 'non-generated' define the specific user subset. There is no redundancy or waste given the rich structured metadata (annotations and schema) handles behavioral and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 100% parameter coverage, the description adequately identifies the resource scope. However, for a complex domain with many user-related siblings, it leaves gaps in explaining the domain-specific filtering ('managed/non-generated') and lacks cross-tool navigation guidance that would help an agent select this over edubase_get_user_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents the search, limit, and page parameters. The description adds no parameter-specific guidance, relying entirely on the schema. This meets the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('List') and resource ('users') with qualifying scope ('managed, non-generated'). It hints at sibling differentiation by specifying a subset of users, though it could clarify what 'managed' and 'non-generated' mean in the Edubase domain to fully distinguish from tools like edubase_get_user_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_get_user (singular), edubase_get_user_search, or edubase_get_user_me. Given the existence of multiple user-retrieval siblings, the lack of explicit selection criteria forces the agent to guess based on parameter schemas alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is safe (readOnlyHint, destructiveHint false) and idempotent. The description adds no further behavioral context such as what the output schema contains (boolean vs object), error handling when the tag isn't attached, or rate limiting details, but does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is immediately front-loaded with the action and target, appropriate for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two string parameters), presence of annotations covering safety, and existence of an output schema, the description is minimally sufficient. However, it lacks completeness regarding the distinction from the plural 'get_video_tags' operation and the specific nature of the check result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('video identification string', 'tag identification string'), the parameters are fully documented in the schema. The description adds no additional semantic information about parameter formats, constraints, or relationships, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check') and resource ('tag attached to a video'), matching the singular naming convention. However, it does not explicitly differentiate from the sibling tool 'edubase_get_video_tags' (which likely lists all tags), potentially leaving ambiguity about whether this returns a boolean, an object, or a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 specific check operation versus retrieving all tags with 'edubase_get_video_tags', nor does it mention prerequisites like needing valid video and tag identifiers beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations correctly indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context that it 'Updates memberships if already member of a class,' clarifying conflict handling. However, it lacks details on authentication requirements, rate limits, or what fields get updated when memberships already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states the primary action, second clarifies the upsert-like behavior with existing members. Information is front-loaded and appropriately scoped for a focused utility tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 4-parameter mutation tool with good schema coverage. Missing information on return values (success confirmation, affected records), error handling (invalid class/user IDs), and whether the operation is atomic (all-or-nothing) or partial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, documenting comma-separated formats, date formats, and default values. The description adds no parameter-specific semantics beyond what's in the schema, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assigns users to classes with specific verbs ('Assign', 'Updates'). However, it does not distinguish from the sibling tool 'edubase_post_class_members' (singular), which likely handles single-class assignments versus this tool's comma-separated batch capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_post_user_classes' (which likely assigns classes to users from the user perspective) or 'edubase_post_class_members' (singular). The description mentions handling of existing memberships but doesn't frame it as a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false). The description adds useful behavioral context by disclosing the upsert behavior ('Updates memberships if already member'), but does not address error cases, return values, or side effects like notifications beyond the parameter default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two efficient sentences with zero redundancy. The primary action is front-loaded in the first sentence, and the second sentence immediately clarifies the upsert behavior without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no output schema, the description adequately covers the core operation and upsert behavior but leaves gaps regarding success/failure responses, the distinction between single and bulk member operations (given the 'classes_members' sibling), and whether the operation triggers notifications or other side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents parameter formats (e.g., comma-separated users, expiry formats). The description mentions 'user(s)' and 'class' but does not add semantic meaning, constraints, or usage examples 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Assign user(s) to a class') and resource, and adds valuable scope clarification by noting it updates existing memberships (upsert behavior). However, it does not distinguish from the similar sibling tool 'edubase_post_classes_members' (plural), which appears to be a bulk variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like 'edubase_post_classes_members' or 'edubase_delete_class_members', nor any mention of prerequisites or preconditions for assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations cover readOnlyHint/destructiveHint, the description adds no behavioral context beyond the schema. It fails to explain the non-idempotent behavior (will it error or duplicate on re-creation?), permission level semantics (what distinguishes 'control' from 'admin'?), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient 7-word sentence with zero redundancy. It is appropriately front-loaded with the action verb and contains no filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (100% coverage) and existence of an output schema, the minimal description is technically adequate. However, it lacks contextual depth regarding the permission hierarchy (view < report < control < modify < grant < admin) and conflict behavior expected for a non-idempotent write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage including enum values for the permission parameter, the schema carries the full semantic load. The description adds no parameter-specific guidance, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Create'), resource ('permission'), and scope ('for a user on an exam'), clearly distinguishing it from sibling tools like edubase_post_class_permission or edubase_delete_exam_permission by explicitly naming the exam resource and create action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., edubase_patch_exam_permission if it existed), prerequisites (e.g., requiring admin rights), or conflict resolution (idempotentHint is false but the description doesn't state what happens if the permission already exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description aligns with 'Create new' implying a write operation, but fails to explain the critical non-idempotent behavior—whether calling twice creates duplicate permissions or errors. It also omits what the tool returns despite the existence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. 'Create new' is slightly redundant but acceptable. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the basic operation is stated, the description lacks completeness given the tool's complexity. It fails to address the non-idempotent behavior (idempotentHint=false), doesn't mention the output schema exists, and omits error conditions (e.g., invalid permission levels, non-existent users). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (all three parameters have clear descriptions including the enum values for permission), the baseline is 3. The description adds no additional parameter context (e.g., format of identification strings, whether user is email or ID), so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and target (permission for a user on a SCORM learning material). It distinguishes from siblings like edubase_delete_scorm_permission and edubase_get_scorm_permission through the verb 'Create' and resource 'SCORM', though it could explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_get_scorm_permission (to check existing permissions) or edubase_delete_scorm_permission (to remove). It also omits prerequisites such as whether the user or SCORM must exist first, or handling of duplicate permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is a non-destructive write operation (readOnlyHint: false, destructiveHint: false), the description adds no context about the non-idempotent behavior (idempotentHint: false)—specifically what happens if the tag is already attached (error vs. duplicate). It also omits reversibility details or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded with the action verb and contains no redundant or wasted words. The length is suitable for the tool's straightforward functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive parameter descriptions, the description adequately covers the basic operation. However, it is incomplete regarding the behavioral implications of idempotentHint: false and lacks error handling context that would help an agent recover from failed invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for both 'scorm' and 'tag' parameters, the baseline is satisfied. However, the description adds no supplementary context such as ID format expectations (UUID vs. slug), case sensitivity, or validation constraints beyond the schema's 'identification string' labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and clearly identifies the resources involved ('tag' and 'SCORM learning material'). It effectively distinguishes this tool from siblings like edubase_delete_scorm_tag (removal) and edubase_post_class_tag (different entity target).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_scorm_tag or edubase_get_scorm_tags. It also omits prerequisites, such as whether the tag or SCORM material must exist beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, covering the critical safety behavior. The description adds context by specifying 'tag attachment' rather than the tag entity itself, clarifying the relationship being destroyed, but does not elaborate on error cases 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately front-loaded with the action verb and contains zero redundant words. It earns its place by clearly stating the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter structure, 100% schema coverage, existence of an output schema, and rich annotations covering safety and idempotency, the description provides sufficient context for correct invocation without needing to document return values or complex behavioral edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already adequately documents both 'event' and 'tag' parameters as identification strings. The description uses the term 'tag attachment' which slightly reinforces the relationship semantics, but adds no specific format constraints or usage details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 target resource ('tag attachment from an event'). While it effectively conveys the action, it does not explicitly differentiate from sibling tools like 'edubase_delete_event_permission' in the description text itself, relying on the tool name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., when to remove a tag vs. deleting an event entirely), nor does it mention prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations correctly declare destructiveHint=true and idempotentHint=true, the description adds no behavioral context beyond restating the action. It does not mention idempotency, error conditions (e.g., if permission doesn't exist), or the effect of removal on existing user sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is tightly focused, front-loaded with the action verb, and contains no redundant or filler text. It efficiently communicates the exact operation without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure (3 flat required fields), complete schema documentation, presence of annotations, and an output schema to define return values, the description is sufficient. A score of 5 would require explicit acknowledgment of the idempotent deletion behavior or output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully self-documenting. The description adds no additional semantic context (e.g., explaining permission level hierarchies or ID formats), warranting the baseline score for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with clear resource scope ('user permission from an integration'), precisely distinguishing it from siblings like edubase_delete_integration (which deletes the entire integration) and edubase_delete_integration_tag (which removes tags).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_post_integration_permission (to add permissions) or edubase_delete_integration (to remove the entire integration). It lacks prerequisites or conditional usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint=true matches 'Remove') and adds the term 'attachment' which clarifies this removes a relationship rather than deleting the tag entity. However, it doesn't mention idempotency (covered by annotation), error cases (e.g., if tag isn't 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler words. The core action is front-loaded and immediately comprehensible. Appropriate length for a simple two-parameter deletion operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (documenting return values), 100% parameter coverage, and comprehensive annotations (destructive, idempotent hints), the description doesn't need to be exhaustive. It adequately covers the core intent, though mentioning idempotency or error behavior would have strengthened it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string', 'tag identification string'), the schema adequately documents parameters. The description adds no additional semantics, format specifications, or examples beyond the schema's generic descriptions, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and scope ('tag attachment from an organization'), distinguishing it from siblings like 'edubase_delete_organization' (which deletes the entity itself). However, it doesn't explicitly clarify whether this deletes the tag permanently or just detaches it from this specific organization, though 'attachment' implies the latter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'edubase_post_organization_tag' (likely the inverse operation) or prerequisites such as requiring the tag to already be attached. The description offers no 'when-not-to-use' exclusions or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (confirming destructive/permanent nature) but adds minimal behavioral context beyond them. It does not disclose side effects (e.g., impact on existing quiz attempts), authorization requirements, or the idempotent behavior already indicated in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words with no redundant information. It front-loads the key action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool with comprehensive annotations (destructive, idempotent hints) and no output schema, the description is sufficient. However, it would benefit from clarifying the distinction from the bulk-delete sibling 'edubase_delete_quiz_questions' to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter 'id' is fully documented in the schema as 'external unique question identifier'. The description adds no additional parameter guidance, meeting the baseline expectation for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (permanently delete) and resource (Quiz question). However, it does not explicitly differentiate from the sibling tool 'edubase_delete_quiz_questions' (plural), which could cause confusion about whether to use this for single vs. bulk deletions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites (e.g., admin permissions), or whether this affects quizzes currently using this question. It states only what the tool does, not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by specifying 'archive' alongside 'Remove', suggesting a soft-delete or recoverable operation rather than permanent deletion. This nuance complements the destructiveHint=true annotation by clarifying the data retention behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at three words. The action is front-loaded and there is no extraneous text, though the brevity borders on under-specification given the destructive nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter deletion tool with comprehensive annotations and full schema coverage. However, it lacks explanation of the archive mechanism, return behavior, or side effects that would help an agent understand the full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'quiz' parameter, the description appropriately relies on the schema for parameter details and does not need to repeat them. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Remove/archive') and target resource ('Quiz set'), distinguishing it from sibling tools that delete quiz components (questions, permissions, tags) by specifying the entire 'set' is targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_delete_quiz_questions' or 'edubase_delete_quiz_tag', nor does it mention prerequisites or recovery procedures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description aligns by using 'Check' but adds no further behavioral context about return values or error conditions. With output schema present, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words, appropriately front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a rich output schema, comprehensive annotations, and simple parameter structure, the brief description is sufficient, though it could benefit from indicating the boolean or verification nature of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear parameter descriptions and enum values. The description mentions the parameters but adds no additional semantic context (e.g., ID formats), warranting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with clear resource ('permission on a class') and scope ('user'), clearly positioning it as a read operation distinct from sibling tools like 'edubase_post_class_permission' or 'edubase_get_class'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives (e.g., when to check permissions vs. get full class details) or prerequisites for the check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the word 'attached' which clarifies the relationship between tags and classes, but doesn't address pagination or response structure (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Front-loaded with action verb. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, comprehensive annotations, and single simple parameter, the description is sufficient. However, it could briefly mention whether empty tag lists return empty arrays or null values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'class' parameter documented as 'class identification string'. Description implies the parameter by referencing 'of a class' but adds no syntax, format examples, or validation rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'List' and resource 'attached tags of a class'. The plural 'tags' distinguishes from sibling 'edubase_get_class_tag' (singular), though it doesn't explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus 'edubase_get_class_tag' (singular) or how to handle classes with no tags. No explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety and idempotency profile. The description adds minimal behavioral context beyond implying a boolean/existence check, and does not describe error cases (e.g., invalid course ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action and target, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 handles return value documentation), full schema coverage, and comprehensive annotations, the description is adequate for this simple two-parameter existence check. A brief note on return value semantics (boolean vs object) would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('course identification string', 'tag identification string'), so the baseline is 3. The description adds no additional parameter semantics, examples, or format specifications beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks tag attachment to a course using specific verb 'check' and resource 'tag attached to a course'. However, it does not explicitly distinguish from sibling tool 'edubase_get_course_tags' (plural), which likely lists all tags versus checking a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_course_tags' (to list all tags) or 'edubase_post_course_tag' (to attach a tag). No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations fully cover the safety profile (readOnlyHint, destructiveHint, idempotentHint), so the description does not need to carry this burden. However, the description adds minimal additional behavioral context beyond confirming the listing operation—it does not mention error cases, authentication requirements, or return value structure (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of eight words with no redundancy. It is front-loaded with the action verb 'List' and every word contributes essential meaning to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one simple parameter, rich annotations covering safety/behavior, and an output schema exists (relieving the description from explaining return values), the description is sufficiently complete. It could be improved by addressing the distinction from the singular 'get_event_tag' variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 references 'an event' which maps to the required 'event' parameter, but does not add syntax details, format examples, or semantic constraints beyond what the schema already provides ('event identification string').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'List' and resource 'attached tags of an event', providing a clear purpose. However, it does not explicitly differentiate from the sibling tool 'edubase_get_event_tag' (singular), which likely retrieves a specific tag rather than all tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_event_tag' (singular) for specific tag retrieval or 'edubase_post_event_tag' for adding tags. There are no prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description aligns with these by stating 'Check' (read operation) but adds minimal behavioral context beyond annotations. It does not clarify return behavior (boolean vs. object) or error handling for non-existent exams/tags, though output schema exists to cover returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Information density is high and the description is appropriately front-loaded with the action verb. Length is well-suited to the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 primitive parameters), comprehensive annotations, 100% schema coverage, and existing output schema, the description provides sufficient context. It does not need to elaborate on return values or deep behavioral edge cases given the structured metadata available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage ('exam identification string', 'tag identification string'). The description references 'tag' and 'exam' but does not add semantic details beyond the schema, such as ID formats or validation rules. Baseline 3 is appropriate given complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Check' with clear resources 'tag' and 'exam', accurately describing the boolean existence check operation. However, it does not explicitly distinguish from sibling tool 'edubase_get_exam_tags' (plural), which likely lists all tags rather than checking a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus alternatives like 'edubase_get_exam_tags' (to list all tags) or 'edubase_get_tag' (to get tag details). No mention of prerequisites such as requiring valid exam/tag IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond confirming the read-only list operation, lacking details on error handling (e.g., exam not found) or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence 'List all attached tags of an exam' is perfectly front-loaded and efficient. Every word serves a purpose with no redundancy or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter), 100% schema coverage, existing output schema, and comprehensive annotations, the description is sufficiently complete. Minor gap: could clarify relationship to singular 'get_exam_tag' tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'exam' parameter, the baseline is 3. The description does not add supplementary parameter details (e.g., ID format examples) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear resource 'attached tags of an exam' and scope modifier 'all'. However, it does not explicitly differentiate from sibling tool 'edubase_get_exam_tag' (singular), which likely retrieves a specific tag rather than listing all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides no guidance on when to use this tool versus alternatives like 'edubase_get_exam_tag', nor does it mention prerequisites such as needing the exam ID beforehand or whether the exam must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations comprehensively cover safety (readOnly, destructive, idempotent hints), so the description's burden is lower. It adds valuable scope context ('owned and managed') beyond annotations, but does not disclose pagination behavior, rate limits, or the search vs. browse interaction detailed in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words with zero redundancy. Every word serves a purpose. However, it borders on under-specification given the tool's behavioral complexity (dual query modes), warranting a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive annotations, the description does not need to exhaustively detail return values. However, it omits guidance on the important interaction between 'search' and 'page' parameters ('not used in search mode!'), which is essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add semantic context beyond the schema (e.g., explaining the search mode vs. pagination behavior or providing example search strings), but it doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with clear resource ('integrations') and scope ('owned and managed'), distinguishing it from the singular 'get_integration' sibling. However, it lacks detail on what constitutes an 'integration' in this Edubase context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes this list operation from singular fetch operations via the plural form and 'owned and managed' qualifier. However, it fails to mention critical usage patterns like the mutual exclusivity of 'search' and 'page' parameters noted in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds minimal behavioral context beyond this, merely stating 'List all attached tags' without addressing pagination, empty result handling, or error conditions for invalid integration IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action verb and avoids repetition of information already present in the tool name or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single required parameter), 100% schema coverage, presence of an output schema, and comprehensive annotations, the description is adequate. However, it could improve by clarifying the relationship to the singular 'get_integration_tag' tool or describing the tag structure briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'integration' parameter ('integration identification string'), the schema carries the semantic burden. The description references 'an integration' which aligns with the parameter but doesn't add format details, examples, or validation rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List), resource (attached tags), and scope (of an integration). It distinguishes from siblings like 'edubase_get_integration' by specifying 'tags' and implies plurality with 'all', though it doesn't explicitly differentiate from the singular 'edubase_get_integration_tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_get_integration_tag' (singular) or 'edubase_get_tags'. There are no stated prerequisites, exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior, lowering the burden on the description. The description adds value by specifying the scope ('owned and managed' organizations), clarifying this returns organizations where the user has ownership or management rights. However, it omits behavioral details like pagination limits or the interaction between search mode and page parameters (though this is documented in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with zero redundancy. It front-loads the essential information (action and resource) and wastes no words, making it appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 obviates the need to describe return values), 100% parameter schema coverage, and comprehensive annotations, the description is sufficiently complete for a list operation. The mention of 'owned and managed' provides necessary scope context, though explicitly contrasting with the singular `get_organization` variant would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema itself fully documents the purpose of 'search', 'limit', and 'page' parameters, including the note that pagination is disabled in search mode. The description adds no additional parameter semantics beyond what the schema provides, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (organizations) with scope qualification (owned and managed). However, it does not explicitly distinguish from sibling tools like `edubase_get_organization` (singular) or `edubase_get_user_organizations`, which would help the agent select the correct tool for fetching a specific organization vs. listing all accessible ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites (like authentication requirements) or when not to use it. The agent must infer usage solely from the tool name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations comprehensively cover the safety profile (readOnlyHint, destructiveHint, idempotentHint), so the description carries a lower burden. The description confirms the read-only nature ('Check') but does not disclose error behaviors (e.g., 404 vs false return when tag doesn't exist) or response structure details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 7 words with zero redundancy. It is front-loaded with the action verb and contains no filler text, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, rich annotations, and simple 2-parameter input with 100% schema coverage, the description is sufficient for tool selection. It does not need to elaborate on return values or complex behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input parameters are fully documented in the structured schema ('organization identification string', 'tag identification string'). The description adds no additional parameter semantics, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly identifies the resource (tag attachment to organization). However, it does not explicitly distinguish this singular check operation from the sibling tool 'edubase_get_organization_tags' (plural) which likely lists all tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_organization_tags' (for listing all tags) or 'edubase_post_organization_tag' (for attaching tags). There are no prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description confirms the read-only list operation but adds no further behavioral context such as error handling when the organization doesn't exist, pagination behavior, or whether the returned tags include metadata beyond names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded with the action verb, contains zero redundant words, and efficiently communicates the tool's purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only operation) and the presence of an output schema, the description is sufficient. However, it could be improved by clarifying the relationship to sibling tag-retrieval tools or noting that it returns tag metadata for the specified organization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('organization identification string'), the schema fully documents the parameter. The description adds no semantic details about the parameter format (e.g., whether it's a UUID, slug, or numeric ID) beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear scope 'all attached tags' and resource 'organization'. The term 'attached' clarifies the relationship between tags and the organization. However, it does not explicitly distinguish from sibling tool 'edubase_get_organization_tag' (singular), though the plural 'tags' in the name helps imply the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_organization_tag' (likely for specific tags) or 'edubase_get_tags' (possibly global tags). It also lacks prerequisites such as needing a valid organization identification string first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds semantic context about the data model—specifically that quizzes contain questions and power exams—which helps the agent understand the resource relationships. However, it does not disclose additional behavioral traits like caching, performance characteristics, or 'not found' behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences with zero redundancy. The first sentence front-loads the action ('Get/check'), while the second provides essential domain context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read operation) and the presence of an output schema, the description is sufficiently complete. It explains what a quiz set is and its relationships. A minor gap is the lack of distinction between singular retrieval versus the list endpoint (edubase_get_quizes).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Quiz identification string'), the schema adequately documents the single 'quiz' parameter. The description adds no specific parameter guidance, but given the high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Get/check') and identifies the resource ('Quiz set'). It adds valuable context that the quiz 'Containing questions and powering Exams,' which distinguishes it from siblings like edubase_get_quiz_questions. However, it fails to clarify that this retrieves a single quiz versus the list operation edubase_get_quizes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_get_quizes (list) or edubase_get_quiz_questions. It does not mention prerequisites, error conditions, or explicit use cases beyond the generic 'Get/check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the qualifier 'detailed' to 'results', implying comprehensive output data, but does not elaborate on what constitutes a 'play', caching behavior, or rate limiting. It neither contradicts nor significantly enriches the annotation-provided behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action ('Get') and immediately specifies the scope ('detailed results for a specific Quiz play'), making it easy to parse during tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (absolving the description from detailing return values), comprehensive annotations, and a single well-documented parameter, the description is nearly complete. The only gap is the lack of differentiation from sibling result-retrieval tools, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'play' parameter ('Quiz play identification string'), the schema carries the semantic load. The description aligns with the schema by mentioning 'Quiz play' but adds no supplementary context about ID format, validation rules, or examples. Baseline 3 is appropriate given the schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed results for a specific Quiz play'), including the scoping qualifier 'specific' which aligns with the 'play' parameter. However, it does not explicitly distinguish from the sibling tool 'edubase_get_quiz_results_user', leaving ambiguity about which results endpoint to use when both user and play IDs are available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (particularly 'edubase_get_quiz_results_user'). It does not mention prerequisites (e.g., needing a play ID from a prior operation) or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the specific behavioral context that this checks attachment existence rather than retrieving data. However, it does not describe what the output indicates (boolean vs. object) or behavior when the tag is not attached, despite the existence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence that immediately communicates the core purpose without repetition or redundancy. Every word earns its place; there is no filler content or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two string parameters, boolean/existence check pattern), the presence of comprehensive annotations, 100% schema coverage, and an output schema, the description provides sufficient context. It adequately explains the operation's purpose without needing to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'scorm' and 'tag' parameters adequately described as identification strings in the schema itself. The description adds no additional semantic context (e.g., format expectations, where to obtain IDs), meeting the baseline expectation when the schema carries the full documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check if') and resource ('tag attached to a SCORM learning material'), clearly indicating this validates a specific attachment relationship. While it implies distinction from the plural sibling 'edubase_get_scorm_tags' through the singular 'tag', it does not explicitly name alternatives or differentiate when to use the list vs. check operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_get_scorm_tags' (which likely lists all tags) or 'edubase_post_scorm_tag' (which attaches tags). No prerequisites, error conditions, or usage constraints are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description confirms the safe read behavior with 'List' but adds no additional behavioral context such as pagination, sorting order, or error handling beyond what annotations and output schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero redundancy. Front-loaded with the action verb and clearly states scope. No filler words or unnecessary preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 comprehensive annotations covering safety hints, the description is adequate for tool selection. Minor gap: could mention behavior when SCORM has no tags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('SCORM identification string'). The description adds no additional semantic information about the parameter format or examples, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and clear resource 'attached tags of a SCORM learning material'. It distinguishes from sibling 'edubase_get_scorm_tag' by specifying 'all', indicating bulk retrieval versus singular access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus the singular variant 'edubase_get_scorm_tag' or tag management alternatives. No mention of prerequisites or error conditions (e.g., invalid SCORM ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the membership scope ('member of') which clarifies the query behavior, but doesn't address pagination, caching, or authorization requirements beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient with no redundant words, front-loading the action. However, given the extensive sibling list with similar names, it is arguably too minimal—one additional sentence distinguishing from edubase_get_classes would improve utility without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with existing output schema and comprehensive annotations, the description meets minimum viability. However, it lacks guidance on the user identifier format and doesn't clarify the relationship to edubase_post_user_classes (add membership) versus this retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('user identification string'), the baseline is 3. The description implies the user parameter by referencing 'a user' but adds no format specifications, examples, or validation rules beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with clear resource 'classes' and distinguishes from siblings via the membership constraint 'a user is member of'. This clearly differentiates it from edubase_get_classes (general listing) and edubase_get_class_members (reverse relationship of class-to-users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like edubase_get_classes (all classes) or edubase_delete_user_classes. It omits prerequisites or context about requiring a valid user identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the valuable qualifier 'latest valid' indicating filtering for non-expired links, but does not clarify what constitutes validity, expiration behavior, or whether retrieving a link affects its status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero redundancy. Critical qualifiers ('latest valid') are front-loaded, and every word serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 handles return value documentation), the single-parameter input schema with full coverage, and comprehensive annotations, the description is sufficient. It could improve by clarifying the distinction from link generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and only one parameter ('user' described as 'user identification string'), the schema carries the full load. The description adds no parameter-specific guidance beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get) and resource (latest valid login link) with scope (for user). However, it does not explicitly differentiate from sibling edubase_post_user_login, which likely generates new links rather than retrieving existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 retrieval tool versus alternatives like edubase_post_user_login (which likely creates/generates links) or edubase_delete_user_login. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'If a valid link with the same settings exists, it will be returned instead of creating a new one,' which describes idempotent behavior. However, the annotations explicitly declare idempotentHint: false. This direct contradiction creates confusion about whether multiple identical calls are truly safe and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two high-value sentences. The first declares the action; the second explains the critical reuse behavior. No filler text, front-loaded information, and zero redundancy given the schema richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (per context signals) and comprehensive parameter documentation, the description appropriately focuses on the high-level behavior (generation vs. reuse). It covers the essential behavioral quirk (idempotency logic) despite the annotation contradiction, though it could note the mutual exclusivity of 'exam' and 'redirect' parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully documented in the schema itself. The description references 'same settings' which loosely alludes to parameters, but adds no specific semantic details (e.g., format requirements, validation rules) beyond what the schema already provides. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate login link') and resource type. The second sentence further clarifies the 'get-or-create' semantics, effectively distinguishing it from sibling tools like edubase_get_user_login (retrieval only) and edubase_delete_user_login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage patterns through the idempotency logic (returns existing valid links), suggesting when to use this versus retrieval. However, it lacks explicit guidance on prerequisites (e.g., user must exist) or explicit comparison to edubase_get_user_login for read-only scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 valuable context by specifying 'attachment' (clarifying this detaches the association rather than destroying the tag entity), but does not disclose additional behavioral traits like error handling, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of seven words with no redundancy. The information is front-loaded and immediately actionable. Every word serves a purpose: 'Remove' (action), 'tag attachment' (specific object), 'from a class' (scope/context).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 (per context signals) and comprehensive annotations covering safety and idempotency, the description provides minimal but adequate coverage for this simple 2-parameter operation. However, it omits edge case behavior (e.g., what happens if the tag is not currently attached) that would elevate it to a 4 or 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions ('class identification string', 'tag identification string'). The description implies the two required parameters but does not add semantic details (format expectations, lookup behavior) beyond what the schema already provides. Baseline 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Remove' with specific resource 'tag attachment' and scope 'from a class'. The phrase 'tag attachment' crucially distinguishes this from deleting the tag entity itself (versus sibling pattern edubase_delete_* for other entity types), and 'from a class' clearly differentiates it from edubase_delete_course_tag and other sibling tag removal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives (e.g., when to remove versus when to delete the tag entirely, or prerequisites like ensuring the tag is actually attached). No explicit exclusions or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the destructiveHint=true annotation by stating 'Remove', but adds no further behavioral context beyond annotations. It does not describe idempotency implications (covered by annotation), error conditions (e.g., if users aren't enrolled), return values, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately front-loaded with the action verb and contains no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter structure, complete schema coverage, and rich annotations (destructive, idempotent hints), the description is sufficient for tool selection and invocation. However, it could be improved by briefly noting the return value or success behavior given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 confirms the plural nature of the operation ('user(s)') which aligns with the comma-separated format of the 'users' parameter, but adds no syntax details, format examples, or semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with clear resource ('user(s)') and scope ('from a class'), precisely matching the tool name and distinguishing it from siblings like 'edubase_delete_class_permission' (permissions vs members) and 'edubase_delete_organization_members' (different resource scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_user_classes' (user-centric removal) or versus removing class permissions. It also fails to mention the complementary 'edubase_post_class_members' tool or prerequisites like requiring valid class/user IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds no further behavioral context (e.g., what happens if the permission doesn't exist, side effects on event access), but does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, efficient sentence with no redundant words. Every word earns its place by conveying the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (not shown in detail but indicated), the description appropriately omits return value details. Combined with comprehensive annotations and schema coverage, the description is complete for a straightforward deletion operation, though it could note the idempotent nature for retry clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('event identification string', 'user identification string', and the permission enum values), the schema fully documents parameters. The description adds no supplementary semantics, meeting the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Remove'), clear target ('user permission'), and scope ('from an event'), precisely distinguishing it from siblings like 'edubase_delete_event_tag' (which removes tags) and 'edubase_post_event_permission' (which adds permissions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., when to delete vs. modify permissions), nor does it mention prerequisites like the user needing to have the permission beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true. The description confirms the destructive nature with 'Remove' but adds minimal context beyond annotations—it does not clarify that the tag object persists after removal or detail error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded with the action and target. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a two-parameter deletion tool with full annotation coverage and an output schema. Could improve by clarifying that neither the quiz nor tag entities are destroyed, only their association.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('Quiz identification string', 'tag identification string'). The description adds no parameter-specific semantics, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Remove' with resource 'tag attachment' and scope 'from a Quiz', clearly distinguishing it from siblings like edubase_delete_quiz (which deletes the quiz itself) and 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives, prerequisites, or that this operation only removes the association (not the tag or quiz themselves).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint=true, readOnlyHint=false) by stating 'Remove', but adds no behavioral context beyond what annotations and schema provide, such as idempotency details, error conditions if the permission doesn't exist, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is front-loaded with the action and contains no redundant words. However, for a destructive operation with three required parameters, it borders on being overly terse rather than optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 comprehensive annotations, the description adequately covers the basic operation but leaves gaps regarding error handling, side effects, or the specific outcome of the removal operation beyond the obvious state change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents the video, user, and permission parameters. The description adds no additional parameter semantics, syntax, or examples beyond the schema definitions, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb (Remove), resource (user permission), and scope (from a video), clearly distinguishing it from sibling tools like edubase_delete_class_permission or edubase_delete_course_permission by explicitly naming the 'video' resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the action verb 'Remove' and the tool name convention, but provides no explicit guidance on when to use this versus alternatives like edubase_post_video_permission (to add) or edubase_get_video_permission (to check), nor prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations clearly mark this as read-only, non-destructive, and idempotent. The description aligns with these traits by using 'Check' and adds context that the operation validates a relationship (attachment) rather than just resource existence. It does not describe the output format, though the presence of an output schema mitigates this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the action verb front-loaded. It contains zero redundant words and immediately communicates the core operation without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter existence check with full schema coverage, output schema present, and comprehensive annotations, the description is adequate. It could be improved by indicating the expected outcome when the tag is not attached (e.g., false vs error), but the structural fields cover the essential contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('event identification string', 'tag identification string'), the baseline score applies. The description references 'tag' and 'event' confirming the semantic mapping but adds no additional format details, validation rules, or examples beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Check if' with clear resources (tag, event) to define the tool's singular purpose. It implicitly distinguishes from sibling edubase_get_event_tags (plural) by focusing on a specific attachment check rather than listing all tags, though it could explicitly mention 'singular' or 'specific' to make the distinction sharper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Check if' phrasing implies usage for verification scenarios versus listing (get_event_tags) or modifying (post/delete_event_tag) operations. However, it lacks explicit guidance on when to prefer this over the plural list endpoint or what to do if the check fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations comprehensively cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the bar is lower. The description confirms the read-only nature with 'Check' but adds no further behavioral context like error handling for invalid users/exams or return value semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. Every word earns its place by stating the exact operation and scope without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 comprehensive annotations, the description is sufficient for tool selection. It could be improved by mentioning the boolean nature of the check result, but the structured context covers the essential gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'exam', 'user', and the permission enum. The description adds no additional parameter semantics, examples, or format details beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clear resource scope ('user has permission on an exam'). It effectively distinguishes from siblings like edubase_get_exam (retrieves exam content) and edubase_post_exam_permission (creates permissions) by specifying this is a verification/read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention typical use cases (e.g., 'verify access before modifying') or explain when to use edubase_get_exam instead for broader exam data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable content context that the tool returns both 'questions and question groups' (not just questions), but does not disclose operational details like pagination, rate limits, or cache behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste: the first defines the operation and scope, the second provides essential domain hierarchy context. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with an output schema present, the description is appropriately complete. It clarifies the domain model (quiz vs exam hierarchy) and content scope (including question groups), though explicit sibling differentiation would strengthen it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the 'quiz' parameter is well-documented in the schema as 'Quiz identification string'. The description references 'Quiz set' which reinforces the parameter's purpose, but adds no syntax or format details beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), resource ('questions and question groups'), and scope ('in a Quiz set'). It distinguishes from exam-related siblings by clarifying the quiz/exam hierarchy, though it doesn't explicitly contrast with singular 'get_question' or generic 'get_questions' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides helpful domain context that quizzes are used by exams, implying this tool is for accessing quiz content rather than exam content. However, it lacks explicit 'when to use' guidance or named alternatives compared to siblings like 'get_question' or 'delete_quiz_questions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, idempotent behavior. The description adds valuable context about the searchable fields (email, username, code) that annotations don't cover, but doesn't disclose additional behavioral traits like exact vs. partial matching, result limits, or case sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded with the action and target, delivering maximum information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema present, the description adequately covers the core functionality. However, it lacks details about return behavior (single vs. multiple results), matching logic (exact/partial), or error conditions that would help the agent handle responses correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema describes the 'query' parameter as a generic 'query string', the description clarifies that this string should be an email, username, or code. This adds meaningful semantic context beyond the 100% schema coverage, helping the agent construct valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (lookup), resource (user), and specific search keys (email, username, code). However, it does not explicitly differentiate from sibling tools like 'edubase_get_user' (which likely retrieves by ID) or 'edubase_get_user_name'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by specifying the valid search inputs (email, username, or code), suggesting when to use this tool. However, it lacks explicit when-to-use/when-not-to-use guidance contrasting it with the 100+ sibling tools, particularly other user retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint: false, destructiveHint: false), so the description does not need to repeat this. However, the description fails to elaborate on the idempotentHint: false annotation—specifically, it does not clarify whether calling this twice creates duplicate permissions, returns an error, or has other side effects. It also does not describe the output schema structure despite its existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action ('Create') and follows with the object and scope. Every word earns its place; there is no fluff or unnecessary repetition of the tool name or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich structured context (100% schema coverage, complete annotations, and existence of an output schema), the description provides sufficient context for a straightforward 3-parameter creation tool. However, it misses the opportunity to mention error conditions (e.g., if permission already exists) implied by idempotentHint: false, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents all three parameters (event, user, permission) including the enum values. The description restates the parameter concepts ('user', 'event', 'permission') but adds no additional semantic context such as ID formats, validation rules, or examples beyond what the schema provides. Baseline 3 is appropriate given the schema carries the full load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource ('permission') and scope ('for a user on an event'). It implicitly distinguishes from siblings like edubase_post_class_permission by specifying 'event', though it does not explicitly differentiate from GET/DELETE variants or mention that this targets the event resource type specifically in text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use when you need to create a permission), but provides no explicit when/when-not guidance. It does not mention that edubase_get_event_permission should be used to check existing permissions first, or that edubase_delete_event_permission is the alternative for removal, leaving agents to infer this from the naming convention alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds crucial behavioral context: 'Updates memberships if already member of the organization.' This disclosure of upsert semantics helps agents understand the tool won't fail if users are already members. It would benefit from mentioning error conditions (e.g., invalid organization ID) or notification 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first states the primary action, the second clarifies the update-on-conflict behavior. Every word earns its place; no redundancy with the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter mutation with full schema coverage and safety annotations, the description adequately covers the core operation and conflict behavior. It lacks output description (success indicators, returned member objects), but no output schema exists to require this. Minor gap: doesn't mention the 'notify' parameter's email side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all 6 parameters including enum values and defaults. The description implies the 'users' parameter through 'user(s)' but doesn't add syntax details (e.g., confirming comma-separated format) or semantic guidance beyond the schema. Baseline 3 is appropriate when schema carries the full load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Assign user(s) to an organization' with a specific verb and resource. It adds the important qualifier that it 'Updates memberships if already member,' clarifying upsert behavior. However, it doesn't distinguish from the sibling tool 'edubase_post_organizations_members' (plural), which could confuse agents about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'edubase_delete_organization_members' or 'edubase_get_organization_members', nor does it clarify the difference from 'edubase_post_organizations_members'. The mention of update behavior implies idempotency considerations but doesn't explicitly guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations by clarifying the upsert behavior (assigning new memberships or updating existing ones). However, it fails to explain why the tool is marked with `idempotentHint: false` despite describing an upsert-like operation, and omits mention of side effects like notifications (controlled by the `notify` parameter) or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient, front-loaded sentences with zero wasted words. The first states the primary action and the second immediately clarifies the update behavior for existing memberships, placing critical information early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive input schema (100% coverage), present annotations declaring the non-read-only, non-destructive nature, and the lack of an output schema, the description provides sufficient context for invocation. However, it could be improved by clarifying the non-idempotent nature and distinguishing usage from similar sibling endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline score is appropriate. The description implies the primary parameters (user and organizations) through the action statement but does not add syntax details, validation rules, or examples beyond what is already documented in the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Assign') and clear resources ('user', 'organization(s)'). It distinguishes the tool's upsert behavior ('Updates membership if already member') from pure create operations, though it does not explicitly differentiate from the sibling tool `edubase_post_organization_members` which likely offers an organization-centric approach to the same action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by noting that it handles both new assignments and existing membership updates. However, it lacks explicit guidance on when to use this user-centric endpoint versus the similar `edubase_post_organization_members` endpoint, or when to use `edubase_delete_user_organizations` for removals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description confirms the destructive action ('Remove') but adds no additional behavioral context such as error handling when the tag isn't attached, side effects, or confirmation that the tag object itself is preserved while only the attachment is removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is appropriately sized for the tool's complexity, front-loaded with the action verb, and contains no redundant or wasted words. Every word serves to clarify the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations describing behavioral traits and an output schema (per context signals), the description provides sufficient context for a simple deletion operation. However, it could be improved by noting the idempotent nature or referencing the inverse operation for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('course identification string', 'tag identification string'), the schema fully documents the parameters. The description adds no semantic details beyond the schema, which is acceptable given the high coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with a clear resource ('tag attachment') and scope ('from a course'). It effectively distinguishes from siblings like edubase_delete_course_permission (which removes permissions) and edubase_delete_class_tag (which targets classes rather than courses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through specificity but lacks explicit guidance on when to use this versus related tools like edubase_post_course_tag (the inverse operation) or edubase_get_course_tags (to verify existence). No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint=true, idempotentHint=true) by stating 'Remove', and adds valuable context that an 'attachment' is being removed rather than the tag entity itself. However, it does not elaborate on error cases, permission requirements, or explicitly reference the idempotent nature 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence with zero waste. The action ('Remove') is front-loaded, and the sentence length is appropriate for a straightforward two-parameter deletion operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, rich annotations (destructive, idempotent hints), and simple 2-parameter structure, the description adequately covers the core operation. Minor gap: it does not explicitly mention the idempotent behavior or error handling scenarios (e.g., if the tag is not attached), though annotations partially cover the former.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string', 'tag identification string'), the schema fully documents parameter semantics. The description does not add additional parameter-specific details, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Remove' with clear resource 'tag attachment' and scope 'from an exam', effectively distinguishing this from sibling tools like edubase_delete_exam (which deletes the exam itself) and edubase_delete_class_tag (which operates on classes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through the specific naming ('tag attachment' vs other exam sub-resources), but lacks explicit guidance on when to use this versus edubase_get_exam_tag first, or how it relates to edubase_post_exam_tag for tag management workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature of the operation ('Remove'), aligning with annotations.destructiveHint=true. However, it adds no behavioral context beyond the annotations, such as explaining the idempotentHint=true (safe to re-invoke) or what the output schema represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is perfectly concise with zero redundancy. It front-loads the action and target, delivering maximum information density with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of rich annotations (destructive/idempotent hints) and an output schema (per context signals), the description provides sufficient context for tool selection. However, it misses the opportunity to mention idempotency or error behavior, which would be helpful for a destructive permission operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully documented in the structured schema (quiz ID, user ID, permission level enum). The description does not add supplementary semantics (e.g., clarifying permission hierarchy or ID formats), warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 quiz'). It effectively distinguishes this tool from siblings like edubase_delete_quiz (deletes the quiz itself) and edubase_delete_quiz_tag (deletes tags) by specifying 'permission' as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for revocation of access, but provides no explicit guidance on when to use it versus edubase_post_quiz_permission (to add permissions) or edubase_get_quiz_permission (to check existing permissions). No prerequisites or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description confirms the destructive nature with 'Remove' but adds no further behavioral context such as error handling when permissions don't exist, side effects on existing user sessions, or cascade behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action verb, zero redundant words. Every element serves a purpose in defining scope (SCORM) and operation (permission removal).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, comprehensive annotations (destructive, idempotent hints), and complete parameter documentation, the description provides sufficient context for a permission deletion tool. Minor gap: does not mention idempotency explicitly or prerequisite checks (e.g., permission must exist), though annotations partially cover this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('SCORM identification string', 'user identification string', enumerated permission levels), the schema fully documents parameters. The description adds no parameter-specific semantics, warranting the baseline score for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with clear resource ('user permission') and context ('SCORM learning material'). It effectively distinguishes from siblings like edubase_delete_scorm_tag (deletes tags, not permissions) and edubase_delete_course_permission (different resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it versus alternatives like edubase_post_scorm_permission (to grant) or edubase_get_scorm_permission (to verify). Usage must be inferred from the verb 'Remove' and the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive write permissions (readOnlyHint: false, destructiveHint: false). The description adds valuable behavioral context beyond these annotations by specifying the storage is 'temporary' and clarifying the prerequisite link-acquisition workflow, which helps the agent understand this is a multi-step process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that efficiently packs the action, source options, destination, and critical workflow prerequisite without redundancy. Every clause serves a distinct purpose in guiding the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter schema and lack of output schema, the description adequately covers the essential workflow context (temporary storage nature and prerequisite link requirement). It could be improved by mentioning what happens upon success or how the uploaded file is referenced subsequently, but the core operational context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter definitions in the schema are comprehensive. The description adds workflow context by implying the `filebin` parameter is the 'link requested from the API in advance' and the `source` parameter accepts 'local file or a file from a URL,' but does not add significant semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Upload), source types (local file or URL), and destination (EduBase temporary file storage). However, it does not explicitly distinguish this tool from sibling `edubase_post_filebin_upload`, leaving potential ambiguity about which tool to use for initiating vs. completing the upload workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite workflow by stating the link must be 'requested from the API in advance,' which hints at execution order. However, it fails to explicitly name the prerequisite tool (likely `edubase_post_filebin_upload`) or clarify when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond confirming this is a verification/check operation. Does not specify behavior when tag is not attached (false vs error), but output schema exists to cover return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Essential information is front-loaded. Length is appropriate for the tool's simplicity (boolean check with two string parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of comprehensive annotations, 100% schema coverage, and an output schema, the description provides sufficient context for this simple idempotent read operation. Could benefit from explicitly noting the boolean nature of the check, but this is implied by 'Check if'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage ('class identification string', 'tag identification string'). Description does not add parameter semantics beyond what the schema provides, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Check' with clear resources ('tag', 'class'). The singular phrasing 'tag is attached' distinguishes this from sibling edubase_get_class_tags (plural) which lists all tags, and from edubase_post_class_tag/edubase_delete_class_tag which modify attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative naming, but the singular 'tag' vs plural 'tags' in sibling tool names provides implied guidance for checking a specific attachment vs listing all attachments. Lacks explicit guidance on when to prefer this over the plural version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description aligns with these by using 'Check' and adds domain context about verifying tag attachment. It does not add details about error cases (e.g., non-existent quiz/tag) or return value semantics, but this is acceptable given the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action ('Check') and immediately clarifies the scope (tag attachment), making it appropriately sized for a simple boolean-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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), 100% schema coverage, rich annotations, and existing output schema, the description provides sufficient context without needing to elaborate on return values. It adequately covers the tool's purpose for an agent to select it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Quiz identification string', 'tag identification string'), the schema fully documents the parameters. The description does not add supplementary semantics (such as ID format examples or lookup methods), warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Check') and clearly identifies the resource (tag attachment to a Quiz). It effectively distinguishes from siblings like 'edubase_get_quiz_tags' (which lists all tags) by specifying this checks a specific attachment relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the singular 'tag' parameter and 'Check if' phrasing, suggesting this is for verifying specific attachments rather than listing. However, it lacks explicit guidance on when to use this versus the plural 'get_quiz_tags' or versus 'post_quiz_tag' and 'delete_quiz_tag'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description confirms the read-only list operation but adds no significant behavioral context beyond annotations, such as pagination behavior, error handling for invalid users, or whether archived memberships are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately front-loaded with the action and scope, delivering maximum information density for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter), presence of an output schema, and comprehensive annotations, the description is sufficiently complete. It could optionally clarify error cases (e.g., user not found) or membership depth, but the current level is adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the 'user' parameter as a 'user identification string'. The description mentions 'a user' but does not add format details (e.g., email vs. UUID) or semantics beyond the schema, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('organizations') with clear scope ('a user is member of'). It effectively distinguishes from siblings like 'edubase_get_organizations' (general list) and 'edubase_delete_user_organizations' (mutation) through the 'List' action and user-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve memberships for a specific user) but provides no explicit guidance on when to choose this over 'edubase_get_organizations' or how it relates to 'edubase_post_user_organizations'. It lacks 'when-not' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description confirms the read-only 'Check' operation but adds no further behavioral context such as error conditions (e.g., invalid video ID), response format details, or caching implications that would supplement the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero redundancy. It front-loads the action ('Check') and includes all necessary qualifying objects (user, permission, video) without filler text or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (handling return value documentation), 100% input schema coverage, and comprehensive annotations covering behavioral hints, the description provides sufficient context for a straightforward permission verification tool. It could improve by noting whether the check returns a boolean or throws an exception on missing permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all three parameters (video, user, permission) are fully documented in the input schema including the permission enum values. The description provides no additional semantic context beyond the schema, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with clear resource ('permission on a video') and scope (user-specific). It effectively distinguishes from sibling tools like edubase_post_video_permission (grant/create) and edubase_get_class_permission (other entity type) through precise naming and action wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'Check' (verification scenarios), but provides no explicit guidance on when to use this read operation versus the POST (grant) or DELETE (revoke) variants, nor does it mention prerequisites like needing valid video/user IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint=false and idempotentHint=false, the description adds crucial behavioral context by clarifying the upsert logic (updates existing memberships rather than failing). This explains the practical implication of the non-idempotent annotation. It does not, however, mention permission inheritance or notification side effects beyond the notify parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two high-value sentences. The first states the primary action; the second clarifies the upsert behavior. There is no redundancy or wasted text, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a 6-parameter write operation with good annotations, the description adequately covers the core functionality and conflict resolution behavior. It appropriately omits return value documentation (no output schema exists), though it could explicitly mention the bulk processing capability given the plural naming convention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the structured documentation already explains all parameters (organizations, users, department, permission levels, notify). The description references users and organizations implicitly but does not add semantic details beyond the schema, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Assign', 'Updates') and clearly identifies the resource (users to organizations). The parenthetical '(s)' and mention of updating existing memberships effectively signals bulk/upsert capability, though it doesn't explicitly distinguish from the singular variant 'edubase_post_organization_members' in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important behavioral guidance by stating it 'Updates memberships if already member,' indicating upsert semantics rather than pure creation. However, it lacks explicit when-to-use guidance versus alternatives like the singular 'post_organization_members' or 'post_user_organizations' variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds conceptual context about quiz sets being collections that can power multiple exams, but does not disclose behavioral details beyond the annotations (such as explaining the cloning behavior implied by copy parameters or confirming the non-idempotent creation behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the action immediately, and the second defines the resource concept. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% coverage, detailed enums) and existence of an output schema, the description is appropriately minimal. However, it could have briefly mentioned the copying workflow or explicitly noted the relationship to the Exam lifecycle given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage including detailed enum explanations for 'mode' and 'type', the description meets the baseline expectation. However, the description text itself adds no parameter-specific semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Create' with resource 'Quiz set' and clearly distinguishes the resource from siblings by explaining quiz sets are reusable collections that 'can be used for practice or to power multiple Exams'—implicitly contrasting with single-use exam resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases (practice and powering exams) but provides no explicit guidance on when to use this versus the sibling 'edubase_post_exam' tool or when to utilize the copy_settings/copy_questions parameters versus creating from scratch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, indicating a safe write operation. The description adds valuable behavioral context about the data model (independent question existence) but omits details about failure modes, duplicate assignment behavior (despite idempotentHint=false), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence front-loads the core action and targets; the second provides essential data model context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, present annotations explaining the safety profile, and no output schema, the description adequately covers the tool's purpose, optional grouping behavior, and entity relationships. Minor gap: does not explain what happens on success or non-idempotent duplicate assignment attempts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'question group' which aligns with the group parameter, but does not add significant semantic detail beyond what the schema already provides for the comma-separated questions format or quiz identification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Assign' with clear resources 'question(s)' and targets 'Quiz set' or 'question group'. The note 'Questions can exist independently from Quiz sets' effectively distinguishes this from creation tools like edubase_post_question and implies this is a linking operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by stating that questions can exist independently from quiz sets, guiding the agent to use this for linking existing questions rather than creating new ones. However, it lacks explicit when-to-use guidance or references to siblings like edubase_delete_quiz_questions for removal operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true, idempotentHint=true) and adds the context that this applies to 'learning material,' but does not disclose additional behavioral traits like the boolean nature of the check or caching behavior beyond what the output schema and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is perfectly front-loaded with the action verb, contains zero redundancy, and every word serves to clarify scope. No wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward permission check with 100% schema coverage, comprehensive annotations, and an output schema present, the description provides sufficient context. No additional explanation of return values or complex workflows is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema adequately documents all three parameters. The description does not add parameter-specific semantics (e.g., format of identification strings), so it meets the baseline expectation where structured data carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Check') and resource ('permission on a SCORM learning material'), clearly distinguishing it from sibling tools like edubase_post_scorm_permission or edubase_get_scorm_tags by implying a read-only verification operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the verb 'Check' implies read-only verification, the description lacks explicit guidance on when to use this versus edubase_post_scorm_permission or what to do with the result. Usage is implied by the naming convention but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, destructiveHint, idempotentHint), so the description's primary added value is the debugging use-case restriction. It does not elaborate on return format, rate limits, or authentication requirements, though the operation is simple enough that major behavioral risks are covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. The core action is front-loaded ('Get the MCP server API URL') and the usage restriction follows parenthetically. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple meta-tool with no parameters. The description covers purpose and usage restrictions. While no output schema exists, the return value (the URL) is implied by the description's verb-object structure; explicit mention of return type would strengthen this to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters exist (schema coverage 100%), establishing baseline 4. The description correctly omits parameter discussion since none are required, aligning with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('MCP server API URL'), distinguishing it from the 100+ sibling tools focused on Edubase entities (classes, exams, users). However, it could clarify whether this returns the base URL for direct API calls or the MCP endpoint itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly restricts usage to debugging scenarios with '(only use for debugging)', providing clear context that this is not for production business logic. Does not name alternatives, but this is acceptable as the tool serves a unique diagnostic purpose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive removal action, aligning with annotations (destructiveHint=true, readOnlyHint=false). However, it adds no behavioral context beyond the annotations, such as explaining idempotent behavior (safe retries), what happens if the tag isn't attached, or whether the SCORM content or tag entity itself is affected versus just the relationship.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. Every word serves to clarify the operation scope and target, making it immediately scannable and actionable without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (removing the need to describe return values), 100% parameter coverage, and comprehensive annotations covering safety hints, the description provides sufficient context for a straightforward relationship-deletion tool. It could be improved by noting idempotency implications or error conditions, but it meets the completeness threshold for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage with basic descriptions ('SCORM identification string', 'tag identification string'), the description adds valuable semantic context that this removes an 'attachment' or relationship between the two entities, not the deletion of the SCORM content or tag itself. This clarifies the nature of the operation beyond what parameter descriptions alone convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('tag attachment from a SCORM learning material'). It effectively distinguishes from siblings like edubase_delete_class_tag or edubase_delete_scorm_permission by explicitly specifying 'SCORM' and 'tag attachment' rather than other resource types or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through the specific resource naming but lacks explicit guidance on when to use this tool versus alternatives (e.g., edubase_post_scorm_tag to add tags) or prerequisites (e.g., checking if the tag exists first). It meets minimum viability but offers no conditional logic or workflow positioning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable domain context by explaining the exam-quiz hierarchy relationship and clarifies the scope limitation to 'owned and managed' exams, which is not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes purpose, second provides necessary domain context about hierarchy. Information is appropriately front-loaded with the action verb leading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, readOnly annotations, and 100% parameter coverage, the description successfully provides sufficient domain context (hierarchy explanation) without needing to detail return values. Minor gap in not explicitly contrasting with singular get_exam.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add parameter-specific semantics, syntax details, or usage patterns beyond what the schema already documents for search, active, limit, and page parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb 'List' + resource 'exams' and clearly defines scope as 'owned and managed.' The additional sentence explaining 'Exams are the highest level in the EduBase Quiz hierarchy' effectively distinguishes exams from quizzes and implies this is a collection endpoint (vs. singular edubase_get_exam).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies this lists multiple exams via the plural naming and 'List' verb, it lacks explicit guidance on when to use this versus edubase_get_exam (singular) or edubase_get_exam_results_user. No 'when-not' or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation), but description adds crucial behavioral context about link caching/reuse that annotations don't capture. This explains the conditional idempotency (returns existing vs generates new). Deducted one point for not defining 'valid' link criteria or clarifying backend side effects (e.g., database record creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total with zero waste. First sentence establishes purpose immediately; second sentence provides essential caching behavior. No redundant filler or repetition of structured data (schema/annotations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (per context signals) and simple 2-parameter input, the description adequately covers the core operation and key edge case (link reuse). Minor gap: does not clarify error scenarios (e.g., missing certificate) or link expiration behavior, though output schema likely handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('exam identification string', 'user identification string'), so baseline 3 is appropriate. Description mentions 'user exam certificate' mapping to both parameters contextually, but adds no additional semantic details about ID formats, validation rules, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Generate' with clear resource 'download link for the latest user exam certificate'. The action clearly distinguishes from sibling tool 'edubase_get_exam_certificates_user' by specifying 'download link' vs implied metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides implicit usage guidance about caching behavior ('If a previous valid link exists, it will be returned instead'), suggesting safe retry semantics. However, it lacks explicit when-to-use guidance versus sibling alternatives like 'edubase_get_exam_certificates_user' or prerequisites for the exam/user parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only and not destructive. The description adds valuable context about the upsert behavior ('Publish or update') and crucial behavioral guidance about type-specific field requirements (e.g., HOTSPOT fields). However, it doesn't disclose error conditions, authentication requirements, or clarify the idempotency implications of the upsert pattern despite idempotentHint being false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two information-dense sentences with zero waste. The first sentence front-loads the purpose and hierarchy context; the second provides actionable guidance on parameter usage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (70 parameters) and presence of an output schema, the description appropriately focuses on high-level behavior and type-specific parameter relationships rather than enumerating fields. It could be improved by explicitly noting the required 'ai' parameter or contrasting with edubase_post_question_id, but it adequately covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds significant semantic value by explaining the relationship between the 'type' parameter and other fields (e.g., 'fields named like the type of the question'), specifically highlighting that HOTSPOT questions require hotspot_zones and hotspot_image. This pattern guidance is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publish or update a question' with specific verbs and resource. It effectively distinguishes from siblings like edubase_post_quiz and edubase_post_exam by explaining the hierarchy (Questions -> Quiz sets -> Exams) and defining questions as 'atomic building blocks' at the 'lowest level'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The hierarchy explanation provides implied guidance on when to use this versus quiz/exam tools. However, it lacks explicit comparison with the sibling edubase_post_question_id tool or clarification on when to use this versus GET/DELETE question tools. The HOTSPOT example provides usage guidance but no explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. Description adds valuable behavioral context not in annotations: the link reuse/caching policy ('returned instead'). Does not mention link expiration or auth requirements, but covers the critical idempotency-like behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total. First establishes purpose; second provides behavioral nuance. Zero redundancy or filler. Information density is optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema and annotations covering safety hints, description adequately covers the operation's purpose and caching behavior. Minor gap: does not define what constitutes 'valid' (TTL/expiry) for existing links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('external unique question identifier'), so the structured data fully documents the parameter. Description does not add parameter-specific semantics, which is acceptable given the high schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Generate' with clear resource 'download link for exporting the question' and specifies format 'JSON'. Distinct from sibling 'edubase_get_question' which retrieves data directly, while this creates an export artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides behavioral guidance via 'If a previous valid link exists, it will be returned instead,' implying caching behavior. However, lacks explicit guidance on when to choose this over 'edubase_get_question' or other question retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, destructive=false), the description adds critical behavioral context: it explicitly states that existing memberships are updated rather than causing duplicates or errors. This clarifies the non-idempotent update semantics despite the annotation idempotentHint=false, though it could further explain what fields get updated (expiry? role?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states the core action, second clarifies the upsert behavior. Every word earns its place; no filler or redundant information. Appropriately front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with good safety annotations and comprehensive input schema, the description adequately covers the operation's scope and side effects. Missing output value description, but no output schema exists to require such documentation. Could mention whether partial failures are possible when assigning multiple classes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents the comma-separated format for classes and the date formats for expires. The description adds no redundant parameter details but implicitly supports the 'classes' parameter semantics through the upsert explanation. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Assign', 'Updates') and clearly identifies the resource (user-to-class membership). It effectively distinguishes from siblings like edubase_get_user_classes (read) and edubase_delete_user_classes (remove), and implies the user-centric direction (vs edubase_post_class_members which is class-centric).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides implicit usage guidance by clarifying the upsert behavior (updates existing memberships rather than erroring). However, it lacks explicit 'when to use' guidance versus similar tools like edubase_post_class_members, and doesn't mention prerequisites or the expires/notify parameters' use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context beyond annotations: the trigger_event constraint explains a prerequisite configuration state. It could improve by mentioning idempotency implications (annotations show idempotentHint=false) or the fact that this makes an external HTTP call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total with zero waste. The first sentence front-loads the core action and resource; the second sentence provides the critical constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters) and lack of output schema, the description is adequately complete. It covers the prerequisite webhook configuration (trigger_event) which is essential for successful invocation. Missing minor details like timeout behavior or retry logic, but these are not required given the annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'optional custom payload' which aligns with the 'data' parameter semantics, but this largely paraphrases the schema's 'custom payload data to be sent' without adding syntax examples or format constraints beyond the schema's 'valid JSON string' requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Trigger' with clear resource 'organizational webhook call' and clarifies the optional 'custom payload' capability. It effectively distinguishes this tool from sibling 'edubase_post_organization_webhook' (which likely creates webhooks) by focusing on execution rather than creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraint that it 'Only triggers webhooks with trigger_event set to api', which defines when the tool will succeed. However, it does not name an alternative tool or method for triggering event-based webhooks, leaving a small gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, destructiveHint), but the description adds valuable domain-specific behavioral context: it clarifies the ownership scope ('owned and managed') and entity structure ('named collections of questions'), helping the agent understand what data subset is returned without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first front-loads the action and scope, while the second efficiently provides essential domain context about hierarchy position. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 comprehensive annotations, the description appropriately focuses on domain context (hierarchy explanation) rather than return values. It adequately covers the tool's purpose and behavioral scope for a listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters (search, limit, page) are fully documented in the schema. The description doesn't add additional parameter semantics (e.g., search syntax specifics), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('List') and resource ('Quiz sets'), clearly distinguishing it from sibling tools like 'edubase_get_quiz' (singular) and 'edubase_get_questions' by specifying 'owned and managed' scope and defining what Quiz sets are within the hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly name alternative tools, the description provides clear contextual guidance by positioning Quiz sets as 'the middle level of the EduBase Quiz hierarchy,' which implicitly signals when to use this tool versus those dealing with individual questions (bottom level) or specific quizzes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations comprehensively cover safety traits (readOnlyHint, destructiveHint, idempotentHint). The description adds the debugging use-case context but does not disclose return format, rate limits, or authentication requirements beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded with the core action and efficiently appends the usage constraint. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, safe read-only annotations) and lack of output schema, the description provides sufficient context for correct invocation without needing to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the input schema, the baseline score applies. The description correctly implies no arguments are needed for this simple retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' with resource 'MCP server version', clearly distinguishing this meta/utility tool from the numerous sibling tools that operate on Edubase domain objects (classes, exams, users, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(only use for debugging)' provides explicit contextual guidance on when to invoke this tool versus other operations, though it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint: false) and non-idempotent. The description adds valuable behavioral context not in annotations: exams are 'time-constrained' (mapping to open/close parameters), 'secured,' and represent 'assessment instances' distinct from their source quiz sets. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states the action, sentence 2 establishes the hierarchy constraint, and sentence 3 describes behavioral characteristics. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 (per context signals), 100% parameter coverage, and comprehensive annotations, the description successfully covers the conceptual model (hierarchy, prerequisites) without needing to document return values or individual parameter types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 implicitly maps to parameters by mentioning 'existing Quiz set' (quiz parameter) and 'time-constrained' (open/close), but does not add syntax details, format specifications, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Create a new exam' and clarifies the unique constraint 'from an existing Quiz set.' It distinguishes from sibling tools like edubase_post_quiz by explaining that exams are hierarchy wrappers around quiz sets, establishing clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a critical prerequisite ('MUST be created from existing Quiz sets') and explains the hierarchy relationship, implying this tool requires a pre-existing quiz. However, it does not explicitly name edubase_post_quiz as the alternative for creating the prerequisite quiz set, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations cover read-only/idempotent hints, the description adds critical behavioral context: the sensitive nature of returned data ('all answers given by the user'), display constraints ('not meant to be displayed'), and authorization requirements ('might require additional permissions'). Minor gap: doesn't mention data volume or privacy implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, zero waste: (1) purpose declaration, (2) usage qualifier, (3) data scope disclosure, (4) display constraint, (5) permission warning. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema (100% coverage), presence of output schema, and comprehensive annotations, the description is complete. It covers purpose, usage constraints, permissions, and data sensitivity without needing to describe return values (handled by output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('exam identification string'), the baseline is met. The description references 'a specific exam' aligning with the parameter, but does not add syntax details, format examples, or semantic clarification beyond the schema's definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Get raw results) and resource (specific exam), and distinguishes itself from sibling tools like 'edubase_get_exam_results_user' by emphasizing 'raw' results and 'very detailed results' including 'all answers given by the user'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Only use this if very detailed results are needed!'), when not to use ('It is not meant to be displayed to the user'), and prerequisites ('This might require additional permissions!'). Clear constraints guide agent selection appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP MCP server](https://glama.ai/mcp/servers/EduBase/MCP/badges/card.svg)](https://glama.ai/mcp/servers/EduBase/MCP)

Score Badge

Copy to your README.md:

[![MCP MCP server](https://glama.ai/mcp/servers/EduBase/MCP/badges/score.svg)](https://glama.ai/mcp/servers/EduBase/MCP)

How to claim the server?

If you are the author of the server, you simply need to authenticate using GitHub.

However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.

{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

Then, authenticate using GitHub.

Browse examples.

How to make a release?

A "release" on Glama is not the same as a GitHub release. To create a Glama release:

Claim the server if you haven't already.
Go to the Dockerfile admin page, configure the build spec, and click Deploy.
Once the build test succeeds, click Make Release, enter a version, and publish.

This process allows Glama to run security checks on your server and enables users to deploy it.

How to add a LICENSE?

Please follow the instructions in the GitHub documentation.

Once GitHub recognizes the license, the system will automatically detect it within a few hours.

If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Latest Blog Posts

Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security
Open Source Has a Bot Problem
By punkpeye on March 19, 2026.
open source

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EduBase/MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server