EduBase MCP Server
OfficialServer Quality Checklist
Latest release: v1.2.15
- Disambiguation3/5
Most tools follow a clear resource+action pattern, but the sheer volume and near-identical variants (e.g., post_exam_settings, patch_exam_settings, put_exam_settings) create ambiguity. The many tag and permission tools differ only by resource type, which can be confusing when selecting the right one.
Naming Consistency4/5Tools predominantly use edubase_ + HTTP verb + resource, which is consistent and predictable. Minor deviations like edubase_get_quizes (misspelling) and edubase_mcp_server_api/version (not verb-noun) prevent a perfect score.
Tool Count1/5With 195 tools, the server is far beyond the typical well-scoped range. While the domain is broad, this count is excessive and likely overwhelms agents, making tool selection inefficient.
Completeness3/5Core quiz/exam/user/org/integration lifecycle operations are well covered. However, resources like courses, events, videos, and SCORM only have tag and permission tools, lacking full CRUD. There are also minor gaps like no create/update for tags themselves.
Average 3.4/5 across 195 of 195 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
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.
This server has been verified by its author.
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.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only the ambiguous 'Get/check', which neither clarifies a return format nor reveals whether it checks existence or retrieves full data—so it does not meaningfully go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The sentence is terse but under-specified. It does not contain enough content to be called appropriately structured; it is merely a placeholder-level phrase that does not convey necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of class-related sibling tools and no explanation of the resource, the description is far from complete. The presence of an output schema does not make up for the absence of any functional or context-defining text; an agent cannot understand what data is affected or what results to expect beyond the bare phrase 'Get/check class'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents the 'class' parameter as a 'class identification string'. The description adds no further meaning to this parameter, so the schema carries the full explanatory burden; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get/check class' but does not define what 'class' refers to in this domain or what 'check' implies. It essentially restates the resource name, so an agent cannot distinguish it from sibling tools like edubase_get_class_assignments or edubase_get_classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool, what context favors it over alternatives, or any preconditions or exclusions. An agent has no guidance on how to choose between this and its many class-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. However, the description adds no behavioral context about what 'check' entails (e.g., does it return a full exam object or just a status?), and thus provides little value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase with no filler, but it is so terse that it borders on under-specification. It is concise but lacks the structure needed to convey the tool's actual function clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter and an output schema present, the basic mechanics are simple. However, the description fails to provide essential context for agent decision-making, such as whether this retrieves an exam or checks existence, and how it differs from edubase_get_exams. The completeness is inadequate given the complex sibling landscape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter description ('exam identification string'), so the schema carries the semantic weight. The tool description does not add any additional meaning or format details, placing it at 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and the resource 'exam', but the addition of 'check' introduces ambiguity: it could mean retrieving full details or merely verifying existence. It also does not differentiate from siblings like edubase_get_exams or edubase_get_exam_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention any distinguishing context, leaving the agent to guess among dozens of exam-related sibling tools.
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 provide destructiveHint=true, idempotentHint=true, openWorldHint=true. Description adds no behavioral context beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two-word description is under-specified, not concise. Lacks structure and front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description omits critical details like side effects, permission requirements, and return behavior. Inadequate for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema has 100% coverage, but description 'Remove organization.' adds no meaning to the 'organization' parameter beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Remove organization.' is vague but conveys the basic action of deleting an organization. It does not differentiate from similar sibling tools like edubase_delete_organization_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites, or consequences. Does not mention alternatives or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, so the safety profile is covered. The description adds no behavioral context beyond the implied GET, and 'check' is ambiguous between existence checking and retrieval. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase is extremely short, but this is under-specification rather than effective conciseness. It eliminates all supporting context that would help an agent select or invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the one-parameter schema, output schema, and annotations reduce the burden, the description fails to clarify what 'tag' refers to or when to choose this over resource-specific tag siblings. An agent cannot confidently distinguish edubase_get_tag from edubase_get_class_tag, edubase_get_quiz_tag, and similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single required parameter 'tag' is documented as 'tag identification string'. The description adds no parameter-level detail, but the schema already carries this burden, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check tag' is essentially a restatement of the tool name; it adds 'check' but does not clarify whether the tool fetches a tag or verifies its existence, nor does it identify the tag domain. Among many siblings like edubase_get_quiz_tag and edubase_get_exam_tag, this provides no 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as edubase_get_tags or the many resource-specific tag endpoints. The description gives no context, exclusions, or alternative routes.
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 the tool as destructive and idempotent. The description adds no extra behavioral context (e.g., whether archiving is reversible, side effects on related data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), which is efficient, but it sacrifices informativeness. It could be expanded without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what happens after deletion (e.g., return value, success indicator). It also fails to differentiate from numerous sibling delete tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'exam' is described in the schema as 'exam identification string'. The tool description does not elaborate on the format, source, or how to obtain it, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove/archive exam,' which indicates the action, but the term 'archive' is ambiguous (soft delete vs. hard delete). It does not differentiate from many sibling delete tools, leading to moderate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives, no prerequisites mentioned, and no exclusions provided. The agent has no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 no behavioral context, such as whether the deletion is soft or hard, or any side effects. It does not exceed what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words), but it is under-specified. It does not provide enough information to be useful, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with one parameter and no output schema, the description is incomplete. It does not explain what constitutes a user identification string, nor any consequences of deletion. The tool needs more context for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (one required 'user' string with a brief description). The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete user,' which is a specific verb+resource. It distinguishes from siblings that delete other entities (e.g., edubase_delete_class_members), but does not provide any additional context or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like edubase_delete_user_classes or edubase_delete_user_assume. The description lacks any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the operation name. It does not mention side effects, authorization requirements, or how the update interacts with organization ownership or external systems. Annotations indicate idempotent and non-destructive behavior, but the description itself contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
'Update integration.' is a single under-specified sentence that simply restates the tool name/title. It is concise but not usefully informative, and it fails to earn its place by adding any operational clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of nuanced behavior around organization ownership and 'none' removal semantics, the description is far too terse. The schema explains some parameter details, but the description provides no broader context about when or how the integration update should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents each parameter. The description adds no parameter-level meaning, but the schema carries the burden, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update integration' clearly identifies the verb and resource, but it is extremely vague about what updating an integration entails. It does not distinguish itself from siblings like edubase_get_integration, edubase_post_integration, or edubase_delete_integration, nor does it mention what fields or behaviors are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool instead of creation, deletion, or retrieval tools, nor does it mention any prerequisites or alternative tools.
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 provide readOnlyHint: false, destructiveHint: false, and openWorldHint: true, indicating mutation but not destructive. The description does not add behavioral context beyond the name and annotations. It does not disclose whether the transfer is reversible, what happens to the original owner, or whether any related data (e.g., members, permissions) is affected. Given the lack of annotation detail, the description should add more behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (five words), which is concise but lacks necessary details. While brevity is valued, this description omits critical contextual information, making it feel under-specified rather than efficiently written. It could benefit from one or two more sentences to clarify usage and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters with good schema coverage, and an output schema exists, so the baseline requirement is moderate. However, the description fails to explain what the transfer does (e.g., changes ownership, assigns admin rights), what user role is required (e.g., admin), or what the output contains. Without this information, an agent cannot reliably decide to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the descriptions are generic: 'user identification string' and 'organization identification string'. These provide no additional meaning beyond the parameter names themselves. The description does not clarify the format of these IDs (e.g., are they numeric, UUIDs, emails?) or explain the semantics of 'user' in this context (e.g., is it the recipient user or the current owner?). The tool's job description offers no parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer organization to user' clearly states the action (transfer) and the resource (organization) and target (user). However, it lacks specificity about the scope or effect of the transfer (e.g., does it transfer ownership, membership, or something else?). Among siblings, there are other transfer tools (e.g., edubase_post_class_transfer, edubase_post_exam_transfer) which follow the same pattern, so the description does not distinguish this tool from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are many sibling tools for transferring various entities (e.g., class_transfer, course_transfer, exam_transfer). The description does not explain under what circumstances an organization should be transferred, or any prerequisites (e.g., user must be a member of the organization). No 'when not to use' or suggested alternatives are given.
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 readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no behavioral detail beyond the verb 'transfer'. It doesn't confirm whether the operation modifies the SCORM's ownership, whether it can be undone, or what side effects (if any) occur. With no annotations for destructive or idempotent, the description should clarify if this is a safe, reversible action, but it remains silent, leaving the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient and directly states the action. It is appropriately concise for a simple tool with only two parameters. However, the brevity comes at the cost of missing crucial context, but for conciseness itself, it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but the description does not mention what the output represents or any side effects. Given the complexity of 'transferring' SCORM (which could involve permissions, ownership changes, or notifications), the single sentence is insufficient. There is no mention of prerequisites, error conditions, or what happens after transfer. The presence of many similar transfer tools (post_course_transfer, post_quiz_transfer) suggests a pattern, but this description alone doesn't leverage that or add specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions 'user identification string' and 'SCORM identification string', so the description adds no value. The tool's description doesn't clarify what 'identification string' means (e.g., UUID, email, internal ID) or any format expectations. Given full schema coverage, the baseline is 3, and no extra semantic info is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool transfers a SCORM object to a user, which is a clear verb+resource+recipient. However, it doesn't distinguish itself from the many sibling 'transfer' tools (e.g., post_course_transfer, post_quiz_transfer) or explain what 'transfer' means in this context (e.g., assigning ownership vs. copying). It is minimally clear but lacks specificity to stand out among the ~160 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 post_scorm_permission or post_scorm_tag. There is no mention of prerequisites (e.g., user must exist, SCORM must be valid) or relationship to permissions. It implies a simple transfer operation but offers no context for choosing it over other SCORM-related actions.
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 non-read-only, non-destructive, non-idempotent, and open-world hint, but the description adds no behavioral context beyond what annotations provide. It does not explain side effects (e.g., whether the original owner retains the video) or required permissions, leaving a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words) and front-loaded. While it sacrifices necessary substance, it avoids any waste. A slightly longer sentence could provide better guidance without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, all required, output schema exists) and the presence of sibling transfer tools, the description is too minimal. It lacks clarification on the transfer's semantics (ownership vs. permission) and any prerequisites. While output schema exists, the description should still provide enough context for an AI to invoke the tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'user' and 'video' described as identification strings. The description adds no additional meaning to these parameters. Baseline 3 is appropriate since the schema already sufficiently documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer video to user' is clear in its verb and resource but fails to differentiate from sibling transfer tools (e.g., edubase_post_exam_transfer, edubase_post_course_transfer). It does not specify what 'transfer' means in this context, leaving ambiguity about whether it changes ownership, grants permissions, or moves the video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternative transfer tools or its prerequisites. There is no mention of context, limitations, or when it should be avoided, making it hard for an AI agent to select correctly among many similarly named 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 already indicate mutation (readOnlyHint=false), safety (destructiveHint=false), idempotency (idempotentHint=true), and open-world (openWorldHint=true). The description adds no behavioral context beyond these annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words) but lacks substance. It does not earn its place by adding value beyond the tool name. More detail about parameters or usage would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the abundance of sibling tools and the absence of an output schema, the description is incomplete. It fails to mention what can be updated (active status) or what the response looks like, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The description 'Update user' does not add any meaning beyond what the schema already provides, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update user' clearly states the verb and resource, distinguishing it from sibling tools like edubase_get_user (retrieve) and edubase_delete_user (delete). It is specific enough for an AI agent to understand the basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, does updating a user with active=false replace deletion? The description lacks any context for usage decisions.
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 merely repeats the destructive nature already indicated by the annotation destructiveHint=true. It adds no extra behavioral context such as whether deletion triggers cascading effects, if it can be undone, or if special permissions are required. The annotations already declare readOnlyHint=false and destructiveHint=true, so the description adds no value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short ('Remove integration.') but lacks informative content. While concise, it is under-specified for a delete operation. The single sentence does not fully earn its place as it repeats the tool name's intent without adding helpful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destruction operation with one required parameter and no output schema, the description is incomplete. It does not explain post-deletion effects, whether related resources (e.g., integration tags) need to be removed first, or what happens if the integration is in use. The sibling tool edubase_delete_integration_tag suggests dependency, but no guidance is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the 'integration' parameter ('integration identification string'), achieving 100% schema coverage. Per the scoring guidelines, the baseline is 3 when coverage is high. However, the description adds no further meaning about the parameter's format, source, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove integration,' specifying the verb (remove) and resource (integration). It distinguishes from sibling tools that operate on other resources (e.g., edubase_delete_question, edubase_delete_exam), but lacks additional context about what kind of integration this refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_patch_integration (update) or edubase_post_integration (create). There are no conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 no further behavioral details, such as whether the deletion is permanent, reversible, or cascades to associated data (e.g., questions). With annotations covering the basics, the description fails to provide additional context about side effects or recovery options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single brief sentence, which is concise. However, it sacrifices useful content (e.g., usage guidelines, behavioral notes) for brevity. Every sentence should earn its place; this one is functional but could be expanded to include more guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is minimal but misses context about what happens upon deletion (e.g., permanent vs. archival, impact on related permissions or questions). The presence of many sibling delete tools increases the need for clearer context to avoid misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the sole parameter (quiz) as 'Quiz identification string', achieving 100% coverage. The description does not add extra meaning or format hints beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove/archive Quiz set' clearly identifies the action (remove/archive) and the resource (Quiz set). It is specific and distinguishes the tool from many sibling delete tools that target other entities (e.g., quiz questions, permissions). However, the slash may imply ambiguity between removal and archiving, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_delete_quiz_questions or edubase_delete_quiz_permission. The description does not specify prerequisites or context for use, leaving the agent to infer from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already clearly indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds minimal behavioral context; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is only two words, which is efficient but may be too terse given the need to differentiate from many similar tools. Could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (not shown), the description is minimal but not entirely insufficient. However, it lacks guidance on usage and differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter 'user', including a note about the 'me' value. The description does not add new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get/check user' indicates a generic retrieve operation, but is vague among many sibling get_user_* tools (e.g., get_user_me, get_user_name). It does not specify what data is returned or how it differs from 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The description does not mention context, prerequisites, or exclusions.
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 the tool as read-only and non-destructive. The description 'Get user's group' adds no behavioral details beyond that, such as what constitutes a group or the format of the response. While the output schema exists, the description itself offers no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it under-specifies. It is efficient but lacks important context that would make it more helpful. A score of 3 reflects the trade-off between brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to provide contextual completeness. It does not explain what 'group' refers to (e.g., primary group, all groups) or how this tool differs from multiple sibling user getters. The agent may not know when to select this tool over others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear parameter description ('user identification string'). The tool description does not add any further meaning to the parameter, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user's group' clearly states the action (get) and resource (user group). However, it does not differentiate from sibling tools like 'edubase_get_user' or 'edubase_get_user_classes', which also retrieve user-related data. A 5 would require explicit 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/5Does 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 such as 'edubase_get_user' or 'edubase_get_user_organizations'. The description lacks context for appropriate deployment.
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 the annotations already provide. It does not explain patch semantics, whether fields are partially updated or replaced, permission requirements, or what happens to existing data. There is no contradiction with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words, making it structurally concise. However, it is under-specified and essentially repeats the tool name, so it does not provide enough substance to score higher.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, a nested custom object, no output schema, and a large set of sibling tools, 'Update organization.' is not sufficient context. An agent receives no information about return behavior, partial-update semantics, or when this tool is the appropriate choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with title, custom, and organization all documented in the input schema. The description itself adds no parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('organization'), clearly indicating the core operation. However, it merely restates the tool name and does not differentiate it from related organization tools such as edubase_post_organization or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like creating a new organization with edubase_post_organization or deleting one with edubase_delete_organization. There is also no mention of prerequisites such as the organization already existing.
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 inform the agent that the tool is idempotent and not destructive or read-only. The description adds no behavioral context beyond the name, failing to disclose what happens when fields are updated or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal. It lacks useful details that could be included without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the presence of annotations, the description should explain what the tool returns or its effects. It only states the action, leaving the agent uninformed about the outcome of the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The tool description does not add any additional meaning or context about how parameters interact or typical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update organizational webhook' clearly states the verb and resource. However, it does not explicitly distinguish from sibling tools like edubase_post_organization_webhook (create) or edubase_delete_organization_webhook, relying on the patch verb implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no information on when to use this tool versus the post or delete alternatives, nor any context on prerequisites or limitations.
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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description adds no behavioral context (e.g., whether the transfer reassigns ownership, requires authorization, or 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks necessary detail. It is too brief to be considered appropriately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many similar transfer tools and the simplicity of this operation, the description should explain side effects and prerequisites. The current description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description ('Transfer class to user') does not add meaning beyond the schema, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer class to user' clearly states the action and resource, but it lacks differentiation from sibling transfer tools like 'post_course_transfer' or 'post_exam_transfer', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description is too brief to help an agent decide between similar transfer operations.
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. Annotations indicate readOnlyHint=false (mutation expected), openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description does not clarify whether the transfer moves or copies the event, replaces ownership, or affects the original user. No contradiction exists, but the description is too sparse to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, which is appropriate given the tool's simplicity. However, it lacks any structured detail or front-loading of critical context such as the effect of the transfer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 only two parameters, the description could be complete with a brief explanation of what 'transfer' means (e.g., reassign ownership, create a copy). The lack of this context makes the description incomplete for understanding the operation's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions ('user identification string', 'event identification string').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer event to user' clearly states the verb (transfer) and the resource (event) with a target (user). It distinguishes from sibling transfer tools like edubase_post_course_transfer by specifying event and user as the entities involved, but does not elaborate on the nature of the transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as other transfer tools or event permission tools. Contexts like prerequisites, ownership implications, or scenarios where transferring is appropriate are absent.
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 the tool is not read-only and not destructive, so the description need not restate that. However, the description adds no context about partial-update semantics, side effects, or permission requirements beyond what annotations imply. Worse, it references an 'export_attendance' setting that does not appear in the input schema, which could confuse an agent into expecting a parameter that does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) and front-loaded with the primary purpose, which is good. But the second sentence about export columns is somewhat convoluted, and the third sentence about a non-existent parameter is unnecessary and could be removed. Overall it is concise but includes one piece of potentially misleading information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 27 parameters and a complex domain, the description should clarify operational semantics and distinguish this tool from its close siblings. It fails to explain whether this is a partial update, how it relates to 'edubase_put_exam_settings', or what the output schema represents. The survey and read-only notes are helpful but not sufficient for an agent to confidently select and call this tool without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all 27 parameters with detailed descriptions, so the baseline is 3. The description, however, adds no meaningful parameter guidance and introduces an undocumented 'export_attendance' setting, which is potentially misleading. It repeats survey restrictions already present per-parameter in the schema, thus failing to add value beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change individual settings of an exam', a clear verb+resource statement that distinguishes it from broad exam creation/deletion tools. However, it does not differentiate from the sibling tools 'edubase_put_exam_settings' or 'edubase_patch_exam_settings' which likely handle full or partial updates, leaving some ambiguity about when this specific tool is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tweaking individual exam settings and provides important constraints (surveys restriction, read-only export_attendance) that guide parameter selection. Yet it never explicitly states when to use this over the put/patch variants, nor does it mention prerequisites like manager permissions or the distinction between partial and full updates.
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 readOnlyHint=false and destructiveHint=false, so the description adds no additional behavioral context. It does not explain what happens if the permission already exists, whether the tool requires admin privileges, or what the side effects are (e.g., does it overwrite or error?). The description is too brief to add value beyond the annotation fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the verb 'Create' and the resource. No wasted words. However, it is so short that it sacrifices substance for brevity, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, enum, output schema exists), the description is minimally adequate. It states the core action. However, it lacks context about return values, error conditions, and the effect of the operation (e.g., adding a permission to a tag's user list). The output schema may cover return values, but the description does not bridge the gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description itself adds no parameter semantics. It does not explain the meaning of each permission level (view, report, control, modify, grant, admin) or clarify that 'tag' and 'user' are unique identifiers. The baseline is 3 due to high schema coverage, but since the description adds zero insight, it scores below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new permission for a user on a tag' clearly states the action (create) and the resource (permission for a user on a tag). It distinguishes from sibling tools for other resources (e.g., edubase_post_class_permission) by specifying 'tag', and from the delete counterpart by using 'Create'. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_tag_permission (to read) or edubase_delete_tag_permission (to remove). It does not mention prerequisites (e.g., tag or user must exist) or warn against duplicate creation (idempotentHint is false). Missing usage context for an agent to make informed decisions.
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, but the description adds nothing beyond the literal 'remove'. It does not clarify that the user must still be attached to the event, whether the operation fails if the permission doesn't exist, or if there are cascading effects. The description fails to add behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste. It is appropriately front-loaded for quick scanning. However, it could be slightly improved by adding a brief note on effect or prerequisites without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simplicity of a 3-parameter delete operation, the description is minimally adequate but lacks guidance on error handling or preconditions. It does not explain the return value (if any) beyond what the output schema might convey, but that is acceptable with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters: event, user, and permission. The description simply repeats the title and does not add any usage notes on parameter constraints (e.g., whether user must be an ID string versus email). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the object ('a user permission from an event'), using a specific verb and resource. While it distinguishes this as a deletion tool among the many permission siblings (e.g., edubase_get_event_permission, edubase_post_event_permission), it could be more precise by noting it removes a specific permission record, not the user from the event entirely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like edubase_post_event_transfer or other permission delete tools. It does not mention prerequisites (e.g., needing admin or grant permission) or when a user should have no remaining permissions, leaving the agent without use-case context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true, but the description merely repeats the title without adding context about what revocation entails (e.g., token invalidation, effect on sessions). No behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (5 words) and front-loaded. However, the brevity sacrifices some clarity about the token's nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and no output schema, the description should explain the effect (e.g., token becomes invalid) and any prerequisites. It lacks this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a single 'token' parameter described as 'assume token'. The description adds no additional semantics, format, or origin information for the token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Revoke assume token' clearly states the action (revoke) and resource (assume token). However, it does not differentiate from similar sibling delete tools, such as edubase_delete_user_login, which might also involve tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_user_assume (which creates tokens) or edubase_delete_user_login. There is no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false, which the description aligns with ('Remove'). However, the description adds no additional behavioral details beyond the annotations. For example, it does not explain idempotency (annotated idempotentHint=true) or what happens when the permission does not exist. The description carries minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, making it very concise and front-loaded. It wastes no words but could be slightly more informative without sacrificing conciseness. The structure is adequate for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters, an output schema, and annotations (including openWorldHint and idempotentHint), the description is too minimal. It does not clarify the behavior when the permission is missing, the format of the response, or any side effects. The output schema is present but not referenced, leaving the agent without full context for correct invocation. More information about idempotency and expected outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already provides descriptions for all three parameters (user, video, permission). The tool description does not add any additional meaning or context for these parameters, so it meets the baseline of 3. No extra clarity is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a user permission from a video' clearly states the action (remove) and the resource (user permission on a video). It readily distinguishes from sibling delete tools (e.g., delete_exam, delete_user) by specifying the resource type. However, it does not explicitly differentiate from the sibling 'edubase_delete_video_permission' itself, but the name makes the resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_video_permission (add) or edubase_get_video_permission (view). There is no mention of prerequisites, required permissions, or scenarios where deletion is appropriate. The description is purely functional, lacking any context about when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no behavioral context beyond duplicating the title, such as the return type or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence (9 words) effectively communicates the core action. Slightly more structure could improve clarity, but it is concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters and an existing output schema, the description lacks contextual details like what the output signifies or typical usage scenarios. It is insufficient for an agent fully to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds no extra meaning, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'permission on an event', distinguishing it from sibling tools like edubase_delete_event_permission or edubase_get_event_tag. However, it does not elaborate on the specific permission levels or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., delete or post). The description provides no exclusions or context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already declare (readOnly, openWorld, idempotent, not destructive). It does not disclose that the tool returns sensitive secrets, any permission requirements, or how the keys are scoped to an integration. With annotations covering the core safety profile, the description's lack of additional context earns a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is minimally concise, but could be slightly expanded to include more context (e.g., the nature of the returned keys) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema, and comprehensive annotations, the description is minimally complete. It does not explain the purpose of integration keys, the format of the output, or how the 'integration' parameter is used. The output schema may cover the return structure, but the description lacks context for a user unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'integration' parameter is described as 'integration identification string'). The tool description does not provide any additional meaning for the parameter. Baseline is 3 due to high coverage; no extra value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get integration keys/secrets' clearly states the action (get) and the resource (integration keys/secrets). It distinguishes itself from siblings like edubase_get_integration (which likely gets integration details) and edubase_post_integration_keys (which creates keys). However, it does not explicitly differentiate itself or elaborate on the relationship between 'integration keys' and the 'integration' parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as edubase_get_integration or edubase_post_integration_keys. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool 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 already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description's burden is reduced. However, it adds no behavioral details beyond the annotations. It does not mention what the return value indicates (e.g., boolean, success/error), nor any side effects or behavior when the tag is not found. Given the annotations cover safety, a score of 2 is appropriate as the description adds little beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, and front-loaded with the main purpose. There is no waste, but it could be slightly expanded to clarify behavior without losing conciseness (e.g., 'Returns whether a tag is attached to a video'). Still, it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (likely a boolean or status) and the context is simple (checking a relationship), the description is too terse. It does not explain what the tool returns (e.g., true/false, or a status object), nor any nuances like case sensitivity or exact match rules. For a simple check tool, this missing information could confuse an agent about how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters ('tag' and 'video') have descriptions in the schema ('tag identification string' and 'video identification string'). The description does not add further meaning, such as formats, examples, or constraints. Baseline 3 is correct since the schema carries the full parametric documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if tag is attached to a video' uses the verb 'check' and specifies the resource ('tag attached to a video'), clearly differentiating it from sibling tools like edubase_post_video_tag (create) and edubase_delete_video_tag (delete). It could be slightly more precise (e.g., 'check existence of a tag on a video'), but it is clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list includes edubase_get_video_tags (list all tags for a video), which is closely related. The description does not explain that this tool checks a single specific tag, while edubase_get_video_tags returns all tags. No context on prerequisites or usage boundaries is 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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds no additional context beyond 'Attach tag to a class', failing to disclose whether the tag or class must pre-exist, whether the operation is additive, or what happens on duplicate attachment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately front-loaded and efficient, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing and high schema coverage, the description lacks essential context about prerequisites (e.g., do tag and class need to exist?), side effects, and return value. For a tool with many similar siblings, more completeness is needed to guide correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described as 'identification string'. The description does not add any extra meaning, examples, or format constraints. Baseline 3 is appropriate since the schema provides full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to a class' clearly states the action (attach) and the resources (tag to a class). It is specific enough to differentiate from sibling tools like delete_class_tag or get_class_tags, though it does not explicitly distinguish from other post_tag tools (e.g., post_course_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many sibling tools for attaching tags to different entities (e.g., post_course_tag, post_event_tag), and the description does not clarify the scope or exclude other use cases.
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 it's a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds no behavioral details beyond a restatement of the action—no mention of idempotency, attachment duplicates, or required entity existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) and front-loaded. However, it is almost too minimal—another sentence could improve completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and an output schema, the description is adequate but lacks details on error conditions, idempotency behavior, or whether the tag must already exist. Leaves questions for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'tag' and 'course' parameters. The description does not add any additional meaning or usage nuance beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to a course' uses a specific verb ('Attach') and specifies the resource ('course'). However, it does not differentiate from siblings like edubase_post_class_tag or edubase_post_exam_tag beyond the resource 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/5Does 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 such as edubase_delete_course_tag or other post-tag tools. The description lacks any usage context, prerequisites, or exclusions.
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 mutability (readOnlyHint false) and non-destructiveness (destructiveHint false). The description adds nothing beyond restating the action. It fails to disclose important behavioral traits such as what happens to the previous owner, idempotency implications, or any side effects. The open world hint implies unlisted behavior, but the description offers no clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently communicates the core action. While very concise, it could slightly elaborate on the transfer semantics without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and clear schema coverage, the description is insufficient for the tool's complexity. It does not explain the implications of transferring a course, any prerequisites (e.g., existing ownership), error conditions, or what the response represents. The agent lacks context to safely invoke this tool among many similar transfers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with basic descriptions for both parameters ('user identification string', 'course identification string'). The tool description adds no additional meaning about parameter formats, constraints, or expected values. It meets the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer course to user' clearly states the verb (transfer), resource (course), and target (user). It identifies the core action and distinguishes from sibling transfer tools by resource type. However, it lacks detail on what 'transfer' entails (e.g., ownership change, enrollment), which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_exam_transfer or edubase_post_class_transfer. There is no mention of prerequisites, when transfer is appropriate, or situations to avoid it. The agent receives no decision-making support.
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 a non-readonly, non-idempotent write operation. The description adds no extra behavioral context such as side effects, permission requirements, or overwrite semantics, except a mild implication of 'reconfigure' meaning updating existing settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the core purpose, containing no wasteful words. It is appropriately short for a simple resource operation, though it lacks enrichment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists and parameters are fully documented, the description omits any practical context such as prerequisites (e.g., shortlink feature requirement) or when not to use the tool. The tool is moderately complex with conditional parameters, so more contextual guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the description does not need to add parameter details. The description does not mention any parameters, but the schema fully documents them, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'enable or reconfigure' and the resource 'automatic login for an exam', making the tool's function evident. It does not explicitly differentiate from sibling get/delete autologin tools, but the name and wording imply a create/update 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting up or altering automatic login but provides no explicit guidance on when to use this tool versus the get or delete autologin siblings, and no 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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'configure or update'. It does not disclose whether the operation is idempotent, replaces existing branding, or requires specific 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It could be slightly expanded to include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of output schema, the description is incomplete. It does not mention return values, error conditions, or that the operation requires an existing exam. Sibling tools provide some context, but the description itself is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add additional semantic value; for example, 'exam identification string' is clear but could specify format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure or update exam branding' clearly identifies the tool's action (configure/update) and resource (exam branding). It distinguishes from siblings like edubase_delete_exam_branding and edubase_get_exam_branding, though it does not explicitly state 'create' vs 'update' behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get or delete). The description lacks contextual triggers, prerequisites (e.g., exam must exist), or exclusions.
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 readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'Submit'. It does not explain side effects (e.g., whether existing summaries are overwritten), required permissions, or rate limits. The openWorldHint=true suggests external factors, but the description offers no clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it is too minimal, sacrificing needed detail. A slightly longer description that front-loads key constraints would be ideal. It earns its place but could be more informative without significant added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (2 required) and no output schema, the description is insufficient. It does not explain the purpose of optional parameters like 'language', 'type', 'llm', or 'model', nor the relationship between 'llm' and 'model'. The schema description for 'summary' already mentions HTML and personal information, but the tool description should summarize these constraints. The lack of output schema means the description should hint at return values, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema. For example, the 'llm' and 'model' parameters have schema descriptions that are adequate. Thus, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit') and the resource ('a new AI exam summary'). The tool name 'edubase_post_exam_summary' aligns with the description, and it is distinct from sibling tools like 'edubase_post_exam' which likely creates the exam itself. However, it does not elaborate on what constitutes an 'AI exam summary' or how this differs from other summary actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 tool, such as prerequisites (e.g., the exam must exist) or situations where alternatives might be preferred. The sibling tools are not differentiated, leaving the agent without context for selection.
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 a non-readonly (write) operation and non-destructive hint. The description adds only the verb 'Transfer' without explaining what that entails—e.g., does it change ownership? Affect previous owner? Require both users to belong to the same organization? No behavioral details beyond the annotation level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, it could be more informative without losing conciseness by including constraints or outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (content unknown), 2 well-described parameters, and annotations, the description fails to explain what the transfer operation actually accomplishes, what side effects occur, or what the response signifies. For a mutation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with 'exam identification string' and 'user identification string' descriptions. The description adds no additional meaning for these parameters beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Transfer' and the resources 'exam' and 'user', making the core action clear. However, it does not differentiate this transfer from sibling transfer tools (e.g., class, course, quiz) which share the same pattern, so the nuance of 'exam transfer' is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_exam_users or other transfer tools. Prerequisites, such as whether the user must already exist or have specific permissions, are absent.
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=false, destructiveHint=false, and idempotentHint=false, indicating a non-idempotent write operation that is not destructive. The description repeats 'Update' but adds no additional behavioral context—no mention of side effects, authentication, rate limits, or what happens on duplicate or conflicting values. Since annotations carry the burden, the description contributes little extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It could briefly mention scope or effect without losing conciseness, but as is, it is efficient and to the point. The trade-off between brevity and completeness is reasonable for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required parameters, no nested objects, output schema present), the description is minimally complete for an agent to invoke the tool. However, it lacks context on whether the metric must pre-exist, error handling, and the scope of 'custom' (e.g., user-specific vs. system-wide). The output schema exists, so return value documentation is not required, but additional usage hints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters ('metric' and 'value'), with detailed schema descriptions (e.g., value accepts increments with a + prefix). The description adds no parameter information beyond what the schema already provides. Per guidelines, high coverage (>80%) sets a baseline of 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a custom metric' clearly states the verb (update) and the resource (custom metric), matching the tool's name and title. There are no sibling tools with a similar name or purpose that cause confusion, so the differentiation is adequate. However, the phrase 'custom metric' remains slightly vague without further context on what constitutes a custom metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any prerequisites or conditions (e.g., whether the metric must already exist). Among many sibling tools, this is a standalone metrics tool, but the description still offers no usage context, leaving the agent to infer intent solely from the name.
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-read-only, non-idempotent write operation. The description adds no new behavioral context such as side effects, required privileges, error conditions, or irreversible consequences. It merely restates the action, contributing nothing 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler, which is efficient and front-loaded. However, it is so brief that it borders on underspecification rather than polished conciseness, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich schema and annotations, the description provides no usage context, prerequisites, or side effects. An agent cannot tell if special permissions are needed beyond the schema note, or what constitutes a successful creation. The output schema helps, but the description is too thin for a tool with 7 parameters and nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed explanations for all 7 parameters, including the special privilege requirement for 'domain' and the 'custom' field mapping. The description itself adds no parameter details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'organization', which unambiguously distinguishes it from sibling operations like patch, delete, or get. However, it lacks any additional context about the organization type or scope, making it clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as edubase_patch_organization for updates or edubase_post_organization_members for membership management. The agent must infer usage solely from the verb 'create', with no exclusions or 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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description 'Attach tag to an organization' adds no behavioral context beyond what annotations already provide. It does not explain whether attaching a tag that already exists is a no-op or an error, or what side effects occur. With annotations present, the description should still add value but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, earning its place with no fluff. It is front-loaded and efficient. However, it is so terse that it sacrifices useful detail, which lowers the score slightly from a perfect 5. It is concise but borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, both required) and the presence of an output schema, the description could be minimal. However, the context includes many sibling tag tools, and the description does not clarify the scope of 'organization' versus other entities. It also does not mention that the tag is likely a reference to an existing tag, leaving the agent to infer. The description is incomplete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters have descriptions ('tag identification string', 'organization identification string'). The description 'Attach tag to an organization' adds no meaning beyond what the schema already provides. Baseline is 3 due to high coverage; the description does not improve or degrade it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach tag') and the resource ('to an organization'). It uses a specific verb+resource pair. However, it does not distinguish itself from many sibling tag-attachment tools (e.g., edubase_post_class_tag, edubase_post_course_tag), which also use the same verb pattern. The purpose is clear but lacks 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools include edubase_post_class_tag, edubase_post_course_tag, edubase_post_event_tag, etc., but the description gives no context for choosing this one. It does not mention prerequisites, such as whether the tag must already exist.
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 readOnlyHint=false, and the description says 'Create', which implies mutation. However, it adds no extra behavioral context such as side effects, required permissions, idempotency concerns, or response handling. With annotations present, the description adds minimal value beyond the safety profile it aligns with.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It fully delivers its minimal content upfront, fitting a short purposeful statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex 13-parameter schema and an output schema that carry much of the context. The description lacks any overview of webhook mechanics or intended use cases, but given the schema's thoroughness and the existence of an output schema, the minimal description is marginally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 13 parameters, so the schema fully documents each field. The description provides no additional parameter information, warranting the baseline score of 3 since it doesn't compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'a webhook for an organization', matching the tool name and distinguishing it from siblings like get, patch, delete, and trigger. It lacks explicit sibling differentiation, but the verb-resource pairing is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only repeats the action without explaining contexts, exclusions, or relationships to sibling webhook operations (e.g., post_organization_webhook_trigger). An agent must infer when creating is appropriate.
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) but the description adds minimal behavioral context beyond 'Set'. It does not disclose side effects, idempotency (annotation says false), permission requirements, or whether the operation overwrites or merges existing identifiers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the core purpose. It is appropriately front-loaded and contains no unnecessary words, though it could be slightly rephrased for even greater clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides adequate purpose but lacks information about constraints, success/failure behavior, or the meaning of the external identifier. Annotations partially fill the gap, but more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already described in the schema. The description adds no further meaning beyond what the schema provides, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'external unique question identifier' for a question. It distinguishes the tool from siblings like edubase_post_question and edubase_get_question_id by specifying the action of setting an external ID, but it does not explicitly contrast with nearby 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/5Does 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_question for creating questions, or edubase_get_question_id for retrieving IDs). No conditions or prerequisites 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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, but the description adds no behavioral context beyond 'update'. It does not explain what 'update' entails (e.g., replaces group or appends), required permissions, or side effects, leaving the agent with minimal insight beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, efficiently front-loading the purpose. It avoids verbosity but still earns its place by stating the tool's action, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description is minimally complete for a simple update operation. However, it lacks context about the nature of 'group' (e.g., code meaning, whether existing group is replaced) and prerequisites, leaving gaps for an agent to fully understand the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with brief descriptions for 'user' and 'group' parameters. The tool description itself offers no additional meaning beyond the schema, providing a baseline but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a user's group' clearly states the verb (update) and resource (user's group), making the tool's purpose evident. However, it does not explicitly differentiate from sibling tools like edubase_patch_user or edubase_get_user_group, leaving some ambiguity about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, exclusions, or context. The single sentence lacks any usage direction, forcing the agent to infer 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?
The description adds no behavioral information beyond the annotations. While annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, the description does not disclose side effects, authorization needs, or behavior on duplicate calls. It simply restates the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that exactly matches the annotation title, making it redundant. While concise, it does not earn its place because it adds no new information beyond the title. Every sentence should contribute unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters with an enum, and an output schema exists, but the description is too minimal. It does not explain the effect of creating a permission (e.g., additive vs. overwrite), prerequisites (user/video existence), or potential side effects. The description lacks completeness for a permission creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the input schema already provides descriptions for all three parameters (user, video, permission) including the enum values. The tool description does not add any additional meaning or context about the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'permission for a user on a video'. It distinguishes itself from sibling tools like edubase_get_video_permission (read) and edubase_delete_video_permission (delete), and from other entity permission tools by specifying 'video'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_class_permission or edubase_post_exam_permission. The description does not mention when not to use it, nor does it reference any prerequisites or alternative 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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already communicate safety and side effects. The description adds no additional behavioral context, such as error behavior or how 'check' differs from a plain get. There is no contradiction with annotations, so a neutral 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. Every word contributes to the basic purpose, and it is appropriately sized for a simple single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema and annotations cover return behavior and safety, the description lacks sufficient context to fully orient an agent: it doesn't clarify whether this is for fetching full organization details or merely checking existence, nor how it relates to the plural get_organizations. For such a simple tool, this is a notable gap in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'organization' is fully described in the schema ('organization identification string'), and schema description coverage is 100%. The description adds no extra meaning or format details beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check organization.' identifies a verb and resource but is ambiguous: 'Get' and 'check' suggest different intents (retrieve vs. verify existence), and it does not clarify whether this targets a single organization versus a list. It distinguishes from sibling get_organizations only by singular form, which is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as edubase_get_organizations or edubase_post_organization. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer appropriate usage.
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 the tool is a write (readOnlyHint=false), non-destructive, non-idempotent, and open-world. The description adds only the verb 'attach', which implies association but not creation. It does not disclose whether duplicate tags are allowed, whether the tag must preexist, or what happens on conflict. The description adds minimal behavioral value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, but it sacrifices utility for brevity. Every sentence should earn its place; here, the single sentence barely provides more than the tool name. It could include additional high-signal information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 simple params, output schema exists) and the presence of many sibling tag-related tools, the description is insufficient. It does not explain behavior like idempotency, error cases, or whether the operation creates or only associates tags. The output schema may cover return values, but the description lacks operational context needed for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (exam, tag) have 100% schema coverage with descriptions like 'exam identification string'. The tool description does not add any additional meaning or context about the parameters (e.g., format, required existence, relationship). With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to an exam.' uses a specific verb ('attach') and explicitly names the resource ('tag') and target ('exam'). This clearly distinguishes it from sibling tools like edubase_get_exam_tags, edubase_get_exam_tag, and edubase_delete_exam_tag, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., delete_exam_tag or post_exam_tag? — there's only one post). No prerequisites, no when-not-to-use, and no mention of whether the tag must already exist. The agent must infer usage entirely from 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 already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds only that it 'creates' a permission, which is consistent but adds no deeper behavioral context: no mention of whether the action is idempotent (though idempotentHint=false is set), how existing permissions are affected (overwrite or additive), or any side effects like triggering notifications. With minimal annotation detail, the description should carry more behavioral weight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, which is very brief. While it effectively states the core purpose, it sacrifices important details that could fit in two or three additional sentences. For a tool with three parameters and a complex permission system (six levels), this level of conciseness is under-specified, earning a score of 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of permissions (six levels, potential conflicts with existing permissions, user-quiz relationship prerequisites), the description is insufficient for an agent to use the tool correctly without external knowledge. The schema covers parameter syntactics but not semantics like 'what does each permission level allow?' or 'can I assign multiple permissions to the same user?'. Even with an output schema, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all three parameters have descriptive names and descriptions in the schema (e.g., permission enum values are listed). The description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema does the necessary work of explaining each parameter's purpose and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create', the resource 'permission', and the scope 'for a user on a quiz'. This distinguishes it from sibling tools like edubase_get_quiz_permission and edubase_delete_quiz_permission which perform different operations on the same resource, and from tools like edubase_post_exam_permission which operate on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether the user must already be associated with the quiz), what happens if a permission already exists, or how this differs from edubase_post_quiz_transfer which also modifies quiz-user relationships. The tool name alone implies the domain, but the description should offer explicit 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?
The description adds no behavioral details beyond what annotations already provide (readOnlyHint=false, destructiveHint=false). It does not clarify what 'transfer' entails (e.g., ownership change, reassignment, permission implications), missing an opportunity to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient but lacks necessary detail. It is front-loaded and not verbose, but under-specification reduces its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and only 2 parameters, the description is still incomplete. It omits usage guidelines and behavioral context, which are important given the many sibling tools with similar names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no insight into parameter meaning beyond the schema's 'identification string' labels (e.g., format, source, constraints), so it does not improve on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfer') and the resource ('tag to user'), distinguishing it from other transfer tools (e.g., edubase_post_class_transfer) and tag-related tools (e.g., edubase_post_tag_permission). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives like edubase_post_tag_permission, edubase_get_tag, or other transfer tools. There are no prerequisites or exclusions mentioned, leaving the agent without context for correct 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?
Annotations already provide: destructiveHint=true (indicates mutation), idempotentHint=true (safe to retry), openWorldHint=true. The description adds 'Remove', confirming the destructive nature. However, it doesn't elaborate on what happens upon success or failure, or if there are cascading effects (e.g., if the tag itself is deleted). Given annotations cover most safety info, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise. However, it is arguably too brief for a tool that requires two parameters and has many siblings. It could benefit from additional context in a second sentence without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and 100% parameter coverage, the description is adequate but not complete. It doesn't clarify return values (though output schema may handle that) or edge cases. For a delete operation, it provides the minimal information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning for the parameters beyond what the schema provides ('tag identification string', 'integration identification string'). The tool name clarifies which IDs are needed, but the description adds no value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a tag attachment') and the target resource ('an integration'). This distinguishes it from sibling tools like 'edubase_post_integration_tag' (which adds a tag attachment) and 'edubase_delete_integration' (which deletes the integration itself). The verb 'Remove' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For instance, there is no mention that this is for removing a tag that was previously attached via 'edubase_post_integration_tag', or any prerequisites like needing an existing tag attachment. The context signals show many sibling tag-related tools, but the description offers no differentiation hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 adds no extra behavioral context beyond 'Remove', such as error behavior on missing entities, reversibility, or side effects. With annotations covering the safety profile, the description provides minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. It is concise but not overly terse; it could include a bit more context (e.g., 'revoke' instead of 'remove') without becoming verbose. It earns its place by stating the action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a destructive tool with 3 required parameters. It does not explain the return value (output schema exists but is not referenced), nor does it mention that the permission must be from the enumerated list (though schema covers that). Given the richness of sibling tools, the description lacks completeness to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The description does not add any additional meaning or usage hints beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and clearly identifies the resource ('user permission from a SCORM learning material'). It distinguishes from sibling tools like edubase_get_scorm_permission (read) and edubase_post_scorm_permission (add), making the tool's action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., edubase_delete_quiz_permission, edubase_delete_exam_permission) or what prerequisites exist (e.g., user must exist, SCORM must exist). The description is silent on when-not-to-use and does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 adds no behavioral context beyond what is structured. It does not mention return type (Boolean likely), what happens if permission is missing (false vs error), or performance implications. For a simple check tool, this is adequate but minimal—the description does not add value beyond existing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but under-specified. It does not elaborate on edge cases or return format. While brevity is good, the description fails to use its space to add value beyond the schema and annotations, essentially repeating the title. It could include guidance on output format or hierarchical permission behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no nested objects, an output schema likely exists), the description is minimally complete. It tells you what it does but not what it returns or how to interpret results (e.g., does permission check respect hierarchies? Is it exact match or inheritance?). The presence of an output schema reduces the burden, but the description still lacks context on permission semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The description adds no extra param meaning, but the schema already fully specifies the string identifiers and enum values. With full coverage, baseline 3 is appropriate, and the description's lack of redundancy keeps it at 3. However, the schema's 'permission' enum is well-documented, so no deduction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks permissions on a course for a user, which matches the name and title. It is distinct from sibling tools like edubase_get_class_permission, which likely checks class-level permissions. A sibling named edubase_post_course_permission exists for granting permissions, so this tool's purpose as a read-only check is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the appropriate tool to verify course permissions, but it offers no explicit guidance on when to use this versus alternatives like edubase_get_class_permission or edubase_get_exam_permission. It does not mention that this is read-only or that it requires specific arguments. No usage exclusions or triggers are provided beyond the schema's required fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, idempotentHint, and non-destructive behavior. The description adds no extra behavioral context such as pagination, response format, or permission requirements beyond simply restating the safe read operation. There is no contradiction with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence with no filler or redundant information. It efficiently conveys the core purpose and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one well-documented parameter, an output schema, and safety annotations, covering the basics. However, the description does not differentiate it from the similarly named 'edubase_get_scorm_tag', which could lead an agent to choose incorrectly when a single tag is needed. This missing context leaves a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'scorm' with the description 'SCORM identification string', achieving 100% coverage. The tool description itself does not add any additional meaning or usage details for the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all attached tags of a SCORM learning material, specifying the verb (list), resource (tags of SCORM), and scope (all attached). It is distinct from the sibling 'edubase_get_scorm_tag' (singular) by the explicit plural 'tags', though it does not 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/5Does 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 instead of similar tag-listing tools (e.g., edubase_get_scorm_tag for a single tag) or when it should be avoided. The usage is only implied by the description's wording, with no explicit context or exclusions.
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 provide the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description should add behavioral context beyond that. It does not disclose partial-update semantics, the effect of empty values (covered only in the schema, not the description), or any authorization requirements. The only addition is the word 'existing,' which is a precondition rather than a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the verb and resource, and every word contributes to the core message. It is concise without sacrificing clarity at the sentence level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a patch operation with six parameters and no output schema, the description is minimally viable but omits tool-level conventions such as whether the update is partial (only provided fields are changed) or full replacement. The rich schema and annotations compensate for many gaps, but an agent may still lack a clear operational picture, especially when choosing between this and quiz_settings tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage, including detailed meanings for each parameter such as empty-value removal and organization move conditions. This baseline of 3 is appropriate because the description itself adds no parameter-level meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and resource (Quiz set), and the word 'existing' tells the agent this tool is for an already-created quiz, not for creation. However, it does not name or distinguish itself from sibling tools like edubase_patch_quiz_settings or edubase_post_quiz, leaving some ambiguity about the exact scope of '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/5Does 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. The description implies the quiz must already exist, but it does not mention related operations like patch_quiz_settings for settings or post_quiz for creating a new quiz, so an agent is left without clear 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 already provide key behavioral hints (readOnlyHint=false, destructiveHint=false). The description adds only 'Create new permission', which is already obvious from the name. It does not disclose whether existing permissions are replaced, whether authorization is needed, or any side effects beyond the basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler. It is appropriately concise but does not attempt to provide richer context. For a minimal viable description, it earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full parameter descriptions, the description lacks critical context for a permission creation operation. It should clarify whether the tool is additive or replaces existing permissions, and mention that user and course must be valid identifiers. The openWorldHint=true suggests creation without strict preconditions, but the brevity leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all three parameters have descriptions in the input schema. The description does not add any new parameter-level information, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new permission for a user on a course' clearly states the action (create), the object (permission), and the context (for a user on a course). It distinguishes this tool from sibling permission tools like edubase_post_class_permission or edubase_post_exam_permission by explicitly naming the resource type 'course' and the user 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are many sibling permission creation tools (for class, exam, quiz, etc.), but the description does not help an agent decide between them. It also omits prerequisites (e.g., user and course must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only (readOnlyHint=false), non-idempotent, non-destructive operation. The description adds no behavioral context beyond the title. It does not clarify side effects, required permissions, or what happens if the tag or integration does not exist, missing an opportunity to aid agent understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no redundancy. It is concise but also lacks informative depth; the efficiency is good, but brevity comes at the cost of context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with two parameters and an output schema exists, the description should at least hint at the expected behavior (e.g., 'Associate an existing tag with an integration'). The current text does not cover the operational context, such as whether either entity must pre-exist or if the operation is a creation of a relationship. This leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions ('tag identification string', 'integration identification string'). The tool description does not add further meaning or format guidance. Per the rubric, baseline 3 is appropriate as the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to an integration' clearly specifies the verb (attach) and the resource (tag to integration). Among sibling tools, many target different entities (class, exam, quiz, etc.), and the name and description together uniquely identify this as the integration-specific tag attachment tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing integration or tag), nor does it distinguish usage from the many other post_*_tag tools beyond the name itself.
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, but the description adds no behavioral context beyond the title (e.g., what happens to the previous owner, required permissions, or side effects). The description fails to disclose the implications of 'transfer' despite carrying the burden alongside sparse 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, for a tool with many siblings, slightly more context would be justified without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required string params) and the existence of an output schema, the description is still too brief. It does not explain the effect of the transfer (e.g., change of ownership, impact on permissions), nor does it help the agent distinguish this from the many other transfer tools. The description is adequate only for the most trivial use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description 'Transfer integration to user' aligns with the schema but adds no additional meaning beyond what the field descriptions already provide (e.g., 'user identification string' and 'integration identification string'). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer integration to user' uses a specific verb ('Transfer') and resource ('integration') plus target ('user'), clearly distinguishing it from sibling transfer tools like edubase_post_class_transfer or edubase_post_exam_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_patch_integration or other transfer tools). There is no context about prerequisites, ownership changes, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at a partial-update behavior with the word 'individual,' implying that only the specified settings are changed and others remain intact. Annotations already convey that the operation is not read-only and not destructive, so the description adds a little context beyond annotations. Still, it does not clearly explain what happens to omitted settings or any validation/error behavior, so it stops at a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence without filler and the core action is front-loaded. It is concise, though it is so short that it lacks some of the context needed for full usability, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of several close sibling tools (get/put/patch quiz settings) and conditional parameter behavior (e.g., roundtime only for turn-based quizzes), the description is not complete enough for an agent to confidently select and invoke this tool. It omits side effects, prerequisites, and how it differs from put/patch variants, leaving important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with detailed descriptions, achieving 100% schema_description_coverage. The tool description adds no parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and object: 'Change individual settings of a Quiz set.' It is easy to understand what the tool does at a high level. However, it does not distinguish itself from sibling tools such as edubase_put_quiz_settings or edubase_patch_quiz_settings, so it lacks the sibling differentiation needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus the many sibling settings tools (e.g., edubase_get_quiz_settings, edubase_put_quiz_settings, edubase_patch_quiz_settings). There is no mention of alternatives, prerequisites, or conditions under which this POST variant is preferred.
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 readOnlyHint=false and destructiveHint=false, so the description adds no extra behavioral context. It correctly implies mutation ('Transfer') but does not disclose potential side effects like ownership changes or permission impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise. However, it could be slightly improved by front-loading key action details like 'Transfers ownership of a quiz to a user.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many similar transfer tools (e.g., class, course, exam transfers), the description lacks distinguishing details. It does not explain what 'transfer' means operationally, nor does it mention expected outcomes or output schema (though optional). The tool's openWorldHint=true suggests dynamic behavior, but no context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('Quiz identification string', 'user identification string'). The description adds no further meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transfer Quiz to user' clearly identifies the action (transfer) and the resource (quiz) and target (user). It distinguishes from sibling tools like edubase_post_class_transfer by specifying the resource. However, it does not elaborate on what 'transfer' entails (e.g., 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/5Does 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, such as other transfer tools or when prerequisites like permissions are needed. The description leaves the agent to infer usage 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 indicate mutability (readOnlyHint false) and non-destructive nature. Description adds the concept of 'assume token' but does not explain behavior like token lifecycle, session scope, or auth requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise (one sentence) with no waste. However, it may be too brief, missing important context like when to use or what the output is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain the side effect (e.g., subsequent requests are as the assumed user), the role of the token, or the lifecycle. Sibling tool edubase_delete_user_assume suggests a need for cleanup, which is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (user, password) are described in the schema. The description adds no extra meaning beyond what the schema provides, such as format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assumes a user for subsequent requests using an assume token. It distinguishes from sibling tools like edubase_delete_user_assume and edubase_post_user_login by focusing on the assumption action. However, the term 'assume token' is ambiguous and lacks explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_login or when to end the assumption (edubase_delete_user_assume). Prerequisites and consequences are not 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 the annotations already convey. Annotations already specify 'destructiveHint: true' and 'idempotentHint: true'. The description does not clarify what happens if the tag or event does not exist, nor any side effects. It simply restates the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, achieving conciseness. However, it lacks structural elements like context or usage notes. For a simple delete tool, this is acceptable but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the annotations covering idempotency and destructiveness, the description is minimally adequate. It does not address potential error cases (e.g., non-existent tag) or the idempotent nature, leaving some gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters having descriptions ('tag identification string', 'event identification string'). The tool description does not add any additional meaning or usage hints for the parameters beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a tag attachment from an event' uses a specific verb ('remove') and clearly identifies the resource ('tag attachment from an event'). It distinguishes this tool from siblings like 'edubase_post_event_tag' (add tag) and 'edubase_delete_event_permission' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or direct users to sibling tools like 'edubase_post_event_tag' for adding tags. The usage context is only inferred from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive, idempotent, and open-world hints, but the description only repeats 'remove' with no additional context on permanence, cascading effects, or side effects. Misses opportunity to explain what 'remove' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about return values, reversibility, or impact on exam state. Given no output schema and destructive nature, more context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both 'exam' and 'users'. The description adds no additional semantic meaning beyond the inline parameter descriptions, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove user(s) from an exam' uses a specific verb and resource, clearly distinguishing it from sibling tools like edubase_delete_exam (deletes the exam itself) or edubase_post_exam_users (adds users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like edubase_delete_class_members or edubase_post_exam_users. No prerequisites or usage conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true and idempotentHint=true, which already indicate that the tool is destructive but safe to retry. The description does not contradict these annotations. However, beyond the annotations, the description adds no additional behavioral context—such as whether removing permissions cascades, requires special authorization, or affects related resources. Since annotations already carry the basic safety profile, the description's lack of extra context earns a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. At 7 words, it wastes no space. While effective, it omits any contextual depth that might be useful, but for clarity and brevity, it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, a clean schema, and an output schema (though not shown here), the bare-bones description is minimally acceptable for a simple CRUD operation. However, it lacks any guidance on preconditions (e.g., does the integration exist? must the user have certain roles?), which reduces completeness. The presence of siblings like edubase_get_integration_permission and edubase_post_integration_permission further suggests that context about the permission lifecycle would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for all three required parameters ('user', 'permission', 'integration'). The description itself does not add meaning beyond what the schema provides—it doesn't clarify format constraints, relationships between parameters, or expected values. Baseline 3 is appropriate given full schema coverage, as the agent can rely on the schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Remove') and resource ('user permission from an integration'), making the tool's purpose immediately understandable. However, it doesn't explicitly distinguish it from sibling tools like edubase_delete_integration (which deletes the entire integration) or edubase_post_integration_permission (which adds permissions), so it misses some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given that there are multiple sibling tools for managing integrations and permissions (e.g., edubase_post_integration_permission, edubase_delete_integration), explicit usage context is absent. The agent must infer that this tool is for removing specific permission assignments, but no when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the basic action. Annotations already signal destructive, idempotent, open-world behavior but the description adds no details about outcomes (e.g., success/failure, remaining members, reversibility).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words, achieving maximum conciseness while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a destructive tool with no output schema. It omits return value, side effects, and any context about what happens after removal, such as error handling or confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (organization and users as comma-separated strings) with 100% coverage. The description adds no additional context beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove user(s) from an organization' clearly states the action and target, distinguishing it from sibling delete tools like edubase_delete_organization and edubase_delete_organization_permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., edubase_post_organization_members for adding, or edubase_get_organization_members for reading). No preconditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description 'Remove' aligns but adds no additional behavioral context (e.g., irreversibility, permission requirements). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words and to the point, but it is arguably too terse, missing any qualifying detail. It earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with well-defined parameters and no output schema, the description is minimally adequate. However, it lacks context on side effects or impact, such as whether deleting a webhook triggers any actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove organizational webhook' uses a specific verb ('Remove') and clearly identifies the resource ('organizational webhook'), distinguishing it from sibling tools like edubase_delete_organization or edubase_delete_organization_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context for deletion, or when not to use it (e.g., if webhook is in use).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows removal is irreversible. The description confirms this operation is destructive, but adds no additional behavioral context beyond the annotations. For example, it doesn't disclose whether dependent objects (like quiz results) are affected, whether cascade deletion occurs, or if specific authorization (e.g., 'admin' permission) is required. The description does not contradict the annotations; thus no contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is front-loaded with the action and resource. However, it could be slightly expanded (e.g., clarifying scope or side effects) without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose, 3 required params, a known output schema (present but not described), and annotations that convey destructiveness. The description is adequate for a simple deletion tool, but it lacks any mention of the output (e.g., what the response looks like) or edge cases (e.g., removing a non-existent permission). Given the output schema exists, explaining the return value is not required, but the description still feels minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – all three required parameters (quiz, user, permission) are described in the schema. The description does not add any additional parameter semantics (e.g., what format quiz or user IDs should follow, what permission values are valid beyond the enum). Since the schema is complete and the description is brief, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a user permission from a quiz' uses the specific verb 'Remove' and clearly identifies the resource (user permission on a quiz). It distinguishes this tool from sibling operations like edubase_post_quiz_permission (add) and edubase_get_quiz_permission (list). However, it does not clarify whether this is a soft delete, revocation, or outright removal, which would strengthen clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are sibling tools for adding (edubase_post_quiz_permission) and listing permissions (edubase_get_quiz_permission), but the description does not mention these alternatives or specify prerequisites (e.g., 'user must have existing permission'). The agent must infer usage context entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true and idempotentHint: true, so the description correctly implies a destructive action. The description aligns with annotations (no contradiction). However, it does not add behavioral detail beyond what annotations already convey, such as whether the tool permanently deletes data or just removes associations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded with the action and resource. Minor improvement would be to clarify the relationship between the two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required params, no output schema, no nested objects), the description is minimally adequate. It tells what it does but not the effect on the system, prerequisites (e.g., user must be in class), or side effects. Sibling tools exist for adding users to classes, so cross-reference would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('user identification string', 'comma-separated list of class identification strings'). The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and the resource 'user from class(es)'. It distinguishes from sibling tools like edubase_delete_user (removes the user entirely) and edubase_post_user_classes (adds user to classes). However, it could be more specific by stating it removes the user's membership, not just the user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. Among siblings, there is edubase_post_user_classes (add) and edubase_delete_class_members (remove from a single class), which are related. No mention of when to prefer this over those or vice versa.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. Description adds no further behavioral context (e.g., cascading effects, required user permissions, or whether relationships beyond membership are affected). It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence of 5 words. No fluff or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 required params and no output schema, but description lacks scope details (e.g., 'Remove user from one or more organizations? Completely or partially?'). Returns/consequences are not mentioned. Incomplete for guiding an agent on expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. Description adds no additional meaning about 'user' or 'organizations' beyond their schema descriptions (e.g., no format, validation rules, or constraints). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (remove) and resource (user from organization(s)). It's concise and unambiguous, distinguishing its destructive removal purpose from sibling tools like edubase_post_user_organizations (add) and edubase_get_user_organizations (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternative removal methods (e.g., edubase_delete_organization_members or edubase_delete_user_classes). No prerequisites or conditions for removal are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only, side-effect-free check. The description aligns with these annotations by stating 'Check if', implying evaluation without mutation. However, it does not add any behavioral information beyond what the annotations already provide (e.g., it does not mention that it may return a boolean or that the check is case-sensitive, nor does it justify the open world hint meaning the tool might return unknown results for missing exams).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is concise and front-loaded. Every word adds value to the purpose. However, it could be improved by adding a sentence about typical use cases or nuances without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only 3 parameters (all with 100% schema coverage), an output schema is present, and simple annotations define safety, the description is adequate but not thorough. It omits information about the return type, error handling (e.g., what if the exam or user does not exist), and the fact that permission checking might be hierarchical (e.g., having admin implies view). The output schema likely describes the response, but the description doesn't guide the agent on interpreting it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level semantics beyond what the schema already provides. All three parameters (exam, user, permission) are described in the schema with brief notes but no additional value from the description. The enum for permission lists valid values, but the description does not clarify the meaning of each level (e.g., view vs. control) or the order of hierarchy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Check if a user has permission on an exam.' This specifies the verb (check), the resource (exam), and the actors (user, permission). The description also implicitly distinguishes from siblings like `edubase_post_exam_permission` (which sets permission via POST) and `edubase_delete_exam_permission` (which removes permission), as those involve mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings or alternatives. For example, it does not mention that this tool is ideal for verification before granting access or that the user and exam information must be known beforehand. The sibling tools include similar permission-checking tools for other resource types (e.g., edubase_get_class_permission, edubase_get_quiz_permission), but the description does not help distinguish between them besides the resource name.
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 provide key behavioral traits (read-only, non-destructive, idempotent, open world). The description adds no extra context beyond these annotations, which is acceptable but does not enhance transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence conveys the tool's purpose effectively without unnecessary words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 simple parameters (2 required strings), the description is minimally adequate. However, it lacks details on ID formats or any constraints, leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema with clear meanings ('exam identification string', 'user identification string'). The description does not add additional semantics beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('user results for a specific exam'). While it doesn't explicitly differentiate from siblings like 'get_exam_results_raw', the name and description imply a specific focus on per-user results, making it distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., 'get_exam_results_raw' or 'get_exam_certificates_user'). It lacks context for selection criteria 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 already convey that this is a read-only, idempotent, non-destructive operation. The description adds no further behavioral context, such as whether the result is cached, requires specific permissions, or has side effects. Since annotations cover the safety profile, the description meets the baseline but adds little value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the action and resource, though it could be slightly more informative without losing conciseness. Overall, it is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, a complete output schema, and annotations covering safety, the description is functionally sufficient. However, it lacks any explanation of what a 'round' is or what the current round represents, which may force the agent to infer semantics from the output schema. This is adequate but not ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'exam' has a schema description ('exam identification string') that fully covers its meaning. The tool description does not add any additional semantic detail beyond the schema, so the baseline score of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('current round of an exam'), which distinguishes it from sibling tools like edubase_post_exam_round. However, it does not elaborate on what a 'round' means or how it relates to exam state, leaving some ambiguity for agents unfamiliar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no preconditions, and no mention of related tools. The only context is the operation name itself, which is insufficient for agents to decide between this and other exam-related getters without deeper inference.
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 traits beyond what the annotations already provide (readOnlyHint, idempotentHint, non-destructive). It does not clarify what 'check' implies (e.g., existence verification, 404 on missing webhook) or any additional context. No contradiction exists, but the description is redundant with the annotation title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the verb and object efficiently, making every word contribute to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two required, fully documented parameters and an output schema, the description is sufficient for an agent to invoke it. Minor gaps include absence of guidance on error behavior when the webhook is not found, but output schema likely covers return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond the schema's terse 'identification string' notes; it merely restates that the webhook belongs to the organization, without further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get/check') and identifies the resource ('webhook configured in organization'). It is not tautological and does not confuse with organization-level or mutation webhook tools, though it does not explicitly distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as the webhook post/patch/delete sibling tools. It does not mention that this is the read-only variant or when one would want to verify webhook configuration.
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?
注释已提供了readOnlyHint=true、idempotentHint=true和destructiveHint=false，覆盖了非破坏性与幂等性。描述补充说明该测验集合包含问题和支撑考试，这提供了一些行为语境，但并未透露比如返回的具体结构、错误情况或权限要求，在已有注释的基础上，此贡献有限但合理。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅用一个短句子，简洁且关键信息（操作、资源、内容）都前置了。虽有小瑕疵（'Containing'缺少主语），但整体没有冗余句子，不失为简明扼要。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
存在输出schema和详细清晰的注解，工具本身也是单一参数的读取操作，复杂性低。描述提供了足够的说明使代理能调用，但缺少与相关工具（如get_quiz_settings、get_quiz_questions）的边界说明，也没有提及任何前置条件或业务上下文，因此中等评分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
唯一参数'quiz'在schema中已有完整描述（'Quiz identification string'），覆盖率为100%。描述没有为该参数增加任何额外意义，比如格式、示例或来源。基于规则，schema覆盖率高时基线为3，描述未提供额外价值，故维持3分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确给出了动作动词"Get/check"和资源"Quiz set"，并补充了其内容（包含问题，驱动考试），足以让代理知晓这是一个查询单个测验的操作。但与同级工具（如edubase_get_quizes、edubase_get_quiz_questions）没有明确区分，代理可能混淆于获取问题列表或设置，因此未到满分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述中完全没有提及何时使用此工具何时使用替代工具，也没有排除条件或前后文情景。只说明了工具的执行范围，缺乏对代理的用法指导。
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, idempotentHint=true, and destructiveHint=false, which cover safety and idempotency. The description reinforces the read-only, checking nature of the tool. No contradiction is present, and the description adds clarity that this is a check (not a list or mutation), which complements the annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately concise and front-loaded with the action. However, it could be slightly more informative (e.g., specifying that it returns a boolean) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required parameters, no enums, output schema exists, annotations cover key traits), the description is mostly complete. The presence of an output schema reduces the need to describe return values. However, the tool does not explain what the output represents (e.g., boolean or full tag details), which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema ('tag identification string', 'Quiz identification string') with 100% coverage. The description adds no extra semantic meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if tag is attached to a Quiz' clearly states the action (check) and the resource (tag-quiz relationship). However, it does not differentiate from siblings like edubase_get_quiz_tags (which retrieves all tags for a quiz) or edubase_get_quiz_tag (which is this tool itself). The description is clear but lacks distinction from 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives such as edubase_get_quiz_tags (lists all tags for a quiz) or edubase_post_quiz_tag / edubase_delete_quiz_tag (add or remove tags). The description does not specify whether this tool returns a boolean or tag details, leaving the AI agent without context to choose correctly.
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, idempotentHint, and destructiveHint=false, so the read-only behavior is covered. However, the description adds no additional behavioral characteristics, such as whether an unknown quiz returns an empty list or an error, or whether tags are directly attached or inherited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that contains no filler words. It front-loads the key action ('List') and target ('all attached tags of a Quiz') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema and read-only annotations, the description is mostly complete. It lacks explicit alternatives, but the combination of the name, description, and schema provides enough context to invoke the operation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the 'quiz' parameter with 100% coverage, so the baseline applies. The tool description does not offer any extra meaning about the identifier's format or lookup semantics beyond confirming it identifies the quiz.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'List' and specifies the resource as 'all attached tags of a Quiz'. While it does not explicitly differentiate from sibling tools like edubase_get_quiz_tag, the plural 'all attached tags' conveys that this is a collection read, which adequately clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as edubase_get_quiz_tag, edubase_post_quiz_tag, or edubase_get_tags. The description only states the function and leaves the selection entirely to the agent.
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, destructiveHint, idempotentHint, and openWorldHint. Description adds no extra behavioral context (e.g., what happens if user not found, privacy constraints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear purpose. Efficient and front-loaded, though very terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with minimal description. Lacks details on output format (though output schema exists), error handling, or format of 'user' parameter. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 1 parameter with description 'user identification string' (100% coverage). Description adds no additional meaning or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'user's name.' It distinguishes from siblings like edubase_get_user and edubase_get_user_me by specifying it retrieves only the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus similar tools like edubase_get_user (which likely returns full user info including name). No when-not or alternative suggestions.
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 the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description adds no additional behavioral details. It does not explain what happens if the tag is already attached, whether the operation is idempotent (idempotentHint=false), or any side effects such as logging or permission requirements. The description relies entirely on annotations, which are already 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, with no wasted text. However, it omits potentially helpful context that could fit in a second sentence without sacrificing conciseness. It is efficient but not optimally informative for a tool with extensive siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, output schema present), the description is minimally adequate. However, it lacks guidance on behavior (e.g., error scenarios, duplicate handling) and does not leverage the output schema to explain return values. It is sufficient for a basic use case but leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters ('event' and 'tag') have descriptions in the input schema. The description adds no supplementary information about parameter formats, allowed values, or relationships between parameters. Baseline 3 is appropriate as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Attach tag to an event.' This clearly identifies the action (attach) and the target resource (event), effectively distinguishing it from sibling tools like 'edubase_post_class_tag' which operate on different entities. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_tags' (retrieval) or 'edubase_delete_event_tag' (removal). It also omits any preconditions (e.g., event and tag must already exist) or postconditions, leaving the agent without context for proper 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, meaning the tool modifies data but is not destructive. The description confirms a create operation. However, it does not add behavioral details beyond what annotations already imply, such as whether permissions are additive, whether duplicates are allowed, or what side effects occur (e.g., does it replace existing permissions?). With annotations covering the mutation nature and non-destructiveness, the description adds minimal extra value for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence of 8 words. It is front-loaded and contains no filler. It earns its place by stating the core purpose. However, it could potentially be slightly more informative while still concise (e.g., mentioning that this is additive or requires existing exam/user). But given the minimalism, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters and an output schema (likely providing confirmation). The description is minimal but paired with the schema and annotations, it is adequate for a basic creation operation. However, it lacks context about idempotency (hint is false, but description doesn't clarify behavior on duplicate), error conditions, or authorization requirements. For a domain with many permission tools, more context on what 'permission' entails (e.g., does it grant a specific role?) would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains each parameter: exam, user, and permission with its enum values. The description does not add any additional semantic meaning beyond the schema. Since schema coverage is high, the baseline is 3, and the description does not exceed that by providing extra context (e.g., how the identification strings are formatted, or relationship to existing permissions). No value is added beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new permission for a user on an exam' clearly states the verb ('Create'), the resource ('permission'), and the target context ('user on an exam'). It is specific enough to distinguish it from the general edubase_post_exam_permission? However, among the sibling tools, there are many similar permission creation tools (e.g., edubase_post_class_permission, edubase_post_course_permission), and the description does not explicitly differentiate them beyond the resource type, which is already implied by the tool name and sibling names. Also, the tool name uses 'edubase_post_exam_permission', which together with the description makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. There are many sibling permission-creation tools (edubase_post_class_permission, edubase_post_course_permission, etc.), but the description does not mention any prerequisites, context, or situations where using this specific tool is appropriate or when to choose another. No exclusions or alternatives are suggested, leaving the agent to infer usage solely from the resource in the name.
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 says 'Rotate' but does not disclose behavioral details such as whether old keys are invalidated, if the operation is reversible, required permissions, or rate limits. Annotations indicate destructiveHint=false and readOnlyHint=false, but the description does not clarify the actual impact of rotation (e.g., possible service disruption). This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, concise sentence that immediately conveys the tool's action. There is no redundant or extraneous text—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and an output schema, the description omits crucial context: it doesn't confirm that the integration must already exist, what the output contains (though output schema exists), or any side effects. An agent cannot reliably use this tool without additional knowledge about rotation semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a description for the single required parameter ('integration identification string'). The tool description adds no additional information about the parameter. Baseline for full coverage is 3, and the description neither adds nor detracts from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rotate integration keys/secrets,' which uses a specific verb ('Rotate') and clearly identifies the resource ('integration keys/secrets'). It distinguishes from sibling tools like edubase_get_integration_keys (retrieval) and edubase_post_integration (creation). This is a clear and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., existing integration) or scenarios where rotation is appropriate. With many sibling tools, such as edubase_get_integration_keys for viewing current keys, the lack of usage direction makes it hard for an agent to decide correctly.
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 openWorldHint=true, suggesting a creation operation with no side effects beyond adding a new permission. The description aligns with this and adds no contradictory behavior. However, it does not disclose behavioral details like whether existing permissions are overwritten, what happens on duplicate entries, or if any impact on existing permissions occurs. Given that annotations already convey basic safety, the description adds minimal value beyond stating the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is front-loaded and efficiently conveys the core purpose. However, it could be slightly improved by including minimal usage context without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema present, the description does not need to explain return values. The description is adequate for a simple creation tool with well-schema-documented parameters. However, it lacks any behavioral nuance or edge-case guidance, which for permission creation could be important (e.g., handling of existing permissions, authorization requirements).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (user, permission, integration) are fully documented in the schema with descriptions. The parameter semantics in the schema cover 100% of the parameters, so the description adds no additional meaning beyond what is already available. The baseline score of 3 is appropriate because the schema is sufficient, and the description does not repeat or enhance the parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new permission for a user on an integration. It uses a clear verb ('Create') and specifies the resource ('permission') and target ('user on an integration'). However, it doesn't differentiate from sibling tools like edubase_post_integration_transfer or the various permission-related tools, though the intention is discernible from the 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/5Does 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_integration_permission or edubase_post_integration_transfer. There is no mention of prerequisites (e.g., whether the user or integration must already exist) or when not to use it. This lack of context could lead to incorrect tool 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 annotations show readOnlyHint=false (indicating mutation) and destructiveHint=false. The description correctly states it 'Create' something, aligning with the mutation expectation. It does not contradict annotations. However, it fails to disclose behavioral details like whether existing permissions are overwritten, what happens to other permissions for the same user on the same organization, or if there are any cascading 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action. It could be improved slightly by being more specific (e.g., what type of user identification), but it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to explain return values. The description is adequate for the tool's complexity (simple create operation with 3 parameters). However, it lacks context about idempotency, whether duplicate permissions are handled, and the relationship to the many other permission tools in the sibling list. It is minimally complete but leaves gaps about behavioral semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all three parameters. The description does not add any extra meaning or usage guidance for the parameters beyond what the schema provides (e.g., it doesn't clarify that 'user' might accept an email or ID, or that 'permission' levels have hierarchical implications). Following the rubric, baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and specifies the resource ('permission for a user on an organization'). It clearly states the action and the two main entities involved. Among sibling tools, there are many other permission creation tools (e.g., edubase_post_class_permission), but the description makes the organization scope clear, which distinguishes it from those other permission 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/5Does 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_organization_members, edubase_get_organization_permission, or the many other permission-related tools. It does not mention prerequisites (e.g., the user must exist), limitations, or when not to use it. The description offers no usage context beyond restating the basic action.
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 (write operation) and destructiveHint=false, the description adds minimal behavioral context. It does not disclose what happens if the tag already exists (error, no-op, or duplication), whether the operation requires the tag to pre-exist in the system, or the scope of side effects (openWorldHint=true but no elaboration). For a mutation tool, key behaviors like idempotency (idempotentHint=false) and error conditions are left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is maximally concise while conveying the core action and subject. Every word is purposeful, and there is no filler content. This is an excellent example of conciseness for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has an output schema (reducing the need to describe return values) and only two required parameters, the description lacks completeness regarding the operation's semantics. It does not clarify whether the tag must already exist, whether the action is additive or replacing, or any constraints on the SCORM identifier. For a tool with such a minimal description, an agent would have to guess important behavioral details, especially given the openWorldHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema ('tag identification string' and 'SCORM identification string'), achieving 100% schema coverage. The description adds no new meaning beyond what the schema already provides; it simply restates 'attach tag to SCORM'. Baseline of 3 is appropriate as the schema carries the semantic load, but the description offers no additional parameter context like expected formats or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 and target ('tag' and 'SCORM learning material'). It effectively distinguishes this tool from sibling tools like get_scorm_tags, delete_scorm_tag, and other entity-tag operations. The purpose is unambiguous and directly communicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to alternatives such as edubase_post_course_tag, edubase_post_exam_tag, or even edubase_delete_scorm_tag. It does not specify prerequisites (e.g., does the tag need to exist? Can it be used to re-attach?) or clarify that it is the correct operation for attaching a tag specifically to a SCORM object as opposed to other entities. Users must infer usage from the tool name 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?
The description clearly states it creates or updates membership, which is appropriate since annotations indicate destructiveHint=false and readOnlyHint=false. The 'Updates membership' note adds transparency beyond annotations. However, it does not disclose what happens to existing permissions not specified (are they preserved or reset?), or whether the operation is reversible. Annotations provide basic safety info, so this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences. The first states the primary action, and the second adds an important edge-case behavior. No extraneous words. While it could be slightly more front-loaded (the title already covers the first sentence), it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and an edge case, but is incomplete for a 7-parameter mutation tool with no output schema. It does not explain what the response looks like (success indicators, error conditions), what happens when required parameters are missing, or how the optional permissions interact (e.g., defaults are documented in schema, but not in description). Given the complexity and lack of output schema, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 7 parameters. The description does not add any additional meaning beyond what the schema provides. However, the param descriptions in the schema are fairly clear (e.g., 'optional name of department', 'comma-separated list of organization identification strings'), so the lack of extra description is acceptable. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign user to organization(s)') and the resource ('user' and 'organization(s)'). It also clarifies edge-case behavior with 'Updates membership if already member of an organization.' This distinguishes it from sibling tools like edubase_get_user_organizations (read) and edubase_delete_user_organizations (delete), but does not explicitly contrast with edubase_post_organization_members, which might have similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when not to use it (e.g., if only reading memberships, use edubase_get_user_organizations), nor does it specify prerequisites (e.g., user must exist or have certain permissions). The description is silent on selection criteria 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?
Annotations already set destructiveHint=true (confirms mutation), readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds nothing beyond "Remove a user permission from a course." The annotation about idempotentHint=true is somewhat surprising for a delete operation, but the description does not clarify or contradict it. No additional behavioral details (e.g., what happens if permission doesn't exist, whether it returns an error or silently succeeds) are provided. This is adequate given annotation coverage but not exemplary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is extremely concise while still conveying the core purpose. It is appropriately sized for a delete operation with well-documented schema parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters (all documented in schema), an output schema (which reduces the burden to explain return values), and annotation-rich context, the description is minimally complete. However, it lacks any edge-case behavior (e.g., removing the last admin permission from a course, or deleting a non-existent permission). The presence of many sibling permission tools (get/post/delete for various entities) makes the absence of differentiation a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – every parameter (user, course, permission) has a description in the input schema. The description adds no further meaning beyond restating the operation. Baseline 3 is appropriate since the schema already documents the parameters well, though the description could explain how permission removal differs or any ordering assumptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states "Remove a user permission from a course", which is a clear verb+resource that specifies exactly what is removed (a user permission) and from where (a course). Among siblings like edubase_get_course_permission and edubase_post_course_permission, this delete variant is sufficiently distinct, though it does not explicitly differentiate from other permission delete tools like edubase_delete_class_permission or edubase_delete_quiz_permission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives (e.g., edubase_post_course_permission to add, edubase_delete_class_permission for class-level removal). It lacks any context about prerequisites, such as whether the user must already have the specific permission, or when it is safe to call (e.g., only if the user has 'grant' authority). There are no exclusions or explicit usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, so the safety profile is clear. The description adds no extra behavioral context beyond the basic listing action. With annotations covering the safety aspect, a score of 3 is appropriate because the description neither contradicts annotations nor adds meaningful behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('List') and the object ('tags of an integration'). There is no redundant information or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with a single well-documented parameter and an output schema, the description is mostly adequate. However, it lacks any guidance on when this tool should be selected over similar tag-listing siblings, which slightly reduces completeness for an agent navigating a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'integration' parameter, described as 'integration identification string'. The description does not add any additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'List all attached tags of an integration.' It specifies a verb ('List') and a resource ('tags of an integration'), and the tool name distinguishes it from singular sibling 'edubase_get_integration_tag'. However, it does not explicitly contrast with the singular variant, which would make it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_tag or edubase_get_tags. There is no mention of context, prerequisites, or exclusions. The usage context must be inferred entirely from the name and 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 indicate read-only behavior. Description adds the 'non-generated' filter, but lacks disclosure of pagination behavior or that search mode disables page parameter (though schema covers this). Minimal added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence that efficiently conveys the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (reducing burden), the description omits clarifying what 'managed, non-generated' means or how this tool relates to other user listing tools. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. Description does not add additional meaning beyond what the schema already provides, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists users with qualifiers 'managed, non-generated'. However, it does not distinguish from sibling tools like edubase_get_user (single user) or edubase_get_user_search, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. No prerequisites or exclusions mentioned, leaving the agent to infer context from sibling names.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond what annotations provide (e.g., no mention of response format, caching, or side effects). It merely restates the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the tool's purpose. No wasted words; it is appropriately concise for a simple read-only check.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, read-only) and the presence of an output schema, the description is minimally complete. However, it lacks context about the permission levels (e.g., hierarchy) and the expected return value, which would aid an agent even with the output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning, constraints, or relationships beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 video' clearly states the verb (check), resource (video), and action (permission). It distinguishes from sibling tools that target other resources (class, course, quiz) or perform different actions (post/delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_video_permission or edubase_get_class_permission. There are dozens of permission-related siblings, and the description offers no context for selection.
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 already indicate this is a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false), the description does not mention any side effects, permission requirements, or constraints like the start-time change limitation described in the parameter 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It immediately conveys the action and subject, and the structure is optimally front-loaded for AI consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (9 parameters, 1 required) and the full parameter documentation, the description is minimally viable. However, it lacks any guidance on typical use cases or return expectations, and with no output schema, an agent may not know what to expect from the response. The annotations mitigate some concerns, but the description itself adds little contextual value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all 9 parameters. The description itself does not add any parameter-specific meaning beyond what is already present, which aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('details of an existing exam'), clearly distinguishing it from sibling operations like edubase_post_exam (create), edubase_get_exam (retrieve), and edubase_delete_exam (delete). The word 'existing' further clarifies it is not for creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or point to other methods (e.g., post_exam for creation, patch_exam_settings for settings changes). Usage is only implicitly inferred from the patch verb.
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 notations indicate this is a mutating operation (readOnlyHint=false, destructiveHint=false). The description adds the context that the link is for temporary storage, which hints at lifecycle behavior but does not elaborate on side effects, expiration, or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It is appropriately concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but, given the presence of an output schema (not shown) and simple parameters, it provides adequate context for a straightforward upload link generation. However, it could mention what the tool returns (e.g., a URL) to aid agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema, covering 100% of parameters. The tool description does not add additional meaning beyond what the schema already provides. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate upload link') and the resource ('temporary file storage'). It is specific and uses a verb+resource structure. However, it does not differentiate from sibling tools like 'edubase_filebin', missing an opportunity to clarify the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, limitations, or scenarios where other tools might be more appropriate.
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: false, idempotentHint: false, and destructiveHint: false, which tells the agent this is a mutation that may not be idempotent. The description aligns (creating a new one is a mutation) but adds no new behavioral context like authentication requirements, consequences of duplicate calls, or side effects beyond what the annotations imply. Given the annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant or extraneous text. It is perfectly front-loaded: the verb and object are in the first few words. There is no filler, making it easy to read in a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 6-parameter tool with a 100% described schema and an output schema present, the one-line description is minimally viable for an agent to understand core purpose. However, it does not cover any usage context or constraints like the fact that for LMS integrations you need type/lti/platform, which the schema hints at but the tool description itself does not reinforce. It also doesn't warn about any limitations or contrast with similar tools, so it's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 6 parameters have descriptions), so the baseline is 3. The description ('Create a new API or LMS integration') adds no tool level detail about parameters beyond what the schema already says; it doesn't mention defaults like 'type' defaulting to 'api', or the condition that platform/lti are required for LMS types. Since the schema covers everything, the description adds little value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new API or LMS integration' states a specific verb (create), the resource (integration), and the two main variants. The action is unambiguous and clearly distinguishes this from read (get_integrations/get_integration), update (patch_integration), and delete (delete_integration) siblings. It does not explicitly name the sibling tools, but the 'create new' phrasing is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as PATCH (edubase_patch_integration) or DELETE (edubase_delete_integration). It also doesn't state when not to use it, nor does it surface context like creating an LMS integration requiring the type, lti, or platform. The schema has these hints, but the description itself is silent about usage 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 readOnlyHint=false and destructiveHint=false, so the description does not need to restate basic write-safety. The description adds some behavioral clarity by saying the tool both publishes and updates, but it does not explain side effects like whether an existing question is overwritten or what happens when the 'id' already exists. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the main action in the first sentence. Each subsequent sentence earns its place by explaining where questions fit in the hierarchy and by cautioning about type-specific required fields. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the enormous parameter surface (79 params) and the existence of an output schema, the description cannot be exhaustive, but it does offer useful orientation and a concrete type-dependent warning. Still, it leaves important context unexplained, such as whether 'publish' vs 'update' is determined by the existence of the provided id, and it does not emphasize the required 'ai' flag that should always be set. The schema covers these gaps partially, but the description alone is not fully complete for such a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds a general heuristic to inspect fields named after the question type and gives the HOTSPOT example, but this is essentially a re-statement of the schema's 'Applicable only for HOTSPOT questions' clauses. It does not provide new format or syntax details beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and object: 'Publish or update a question.' It also adds valuable context by placing questions in a hierarchy (Questions -> Quiz sets -> Exams), helping the agent understand the domain. However, it does not explicitly distinguish itself from related siblings like edubase_post_question_id, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 an alternative. It does not mention edubase_post_question_id, edubase_get_questions, or any other sibling as a better fit for a specific scenario. The advice given is strictly about parameter selection for certain question types, not about tool selection.
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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds no behavioral context beyond a simple mutation verb. It does not disclose what happens if the tag is already attached, whether the operation is idempotent, or any permission/authorization requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of four words that is front-loaded and clear. Every word is necessary; there is no extraneous or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two string parameters and an output schema, the description is adequate but minimal. It lacks behavioral details such as idempotency, error conditions (e.g., duplicate tag), or side effects. While the output schema likely covers return values, the description could be more complete for an agent to successfully invoke the tool without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters having basic descriptions ('tag identification string', 'Quiz identification string'). The tool description adds no additional parameter meaning, format hints, or examples. Baseline score of 3 is appropriate when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to a Quiz.' is a specific verb+resource pair that clearly states the action and target. It distinguishes from siblings like edubase_delete_quiz_tag (removal) and edubase_get_quiz_tags (listing), and from similar post_tag tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to attach vs. delete a tag, or how it differs from other post_tag operations). The description does not include any when-to-use, when-not-to-use, or prerequisite information.
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=false, destructiveHint=false, and idempotentHint=false. The description adds minimal behavioral context beyond 'Create new permission'—it does not disclose whether the call fails if the permission already exists, what authorization is needed, or how the system behaves under conflicts. Given that annotations cover the basic safety profile, the description contributes little extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. Every word earns its place, providing the essential action, resource, and context with zero fluff. This is ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters, an enum, and an output schema (not shown but noted). For a simple creation operation, the description is arguably sufficient to convey the core action. However, it lacks preconditions (e.g., user/SCORM existence) and any mention of idempotency or side effects. With the output schema present, the missing return-value explanation is acceptable, but the overall guidance for the agent is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter (user, scorm, permission) already has a meaningful description in the schema. The tool description adds no additional parameter-level meaning beyond the schema. Baseline 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), identifies the resource ('permission'), the target entity ('SCORM learning material'), and the actor ('user'). It clearly distinguishes from sibling tools like edubase_get_scorm_permission (read) and edubase_delete_scorm_permission (delete), as well as permission tools for other entities (e.g., edubase_post_class_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/5Does 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. There is no mention of prerequisites (e.g., user or SCORM material must exist), nor any indication of when not to use it. While the name and resource imply context, the description lacks the 'when-not-to-use' and 'alternative' clarity expected for a 4+ score.
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 destructiveHint=true and idempotentHint=true. The description 'Remove' is consistent but adds no additional behavioral context, such as whether removal is permanent, permissions required, or effect on non-existent permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. It is front-loaded with the action, but lacks some important usage details that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters and an output schema, but the description does not explain the return value, error conditions, or prerequisites for using this tool. Given the existing annotations and schema, the description is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description does not add any additional meaning or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and identifies the resource 'user permission from a class'. It clearly distinguishes from siblings like edubase_post_class_permission (add) and edubase_get_class_permission (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., other delete permission tools, or when to use post vs delete). No prerequisites or context for usage are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no behavioral context beyond stating the action of removing. It does not describe side effects, edge cases (e.g., removing a non-existent permission), or authentication needs. Since annotations carry the burden, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single six-word sentence that communicates the core purpose without any unnecessary text. It is front-loaded and leaves no filler, earning top marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context for a destructive operation. It does not explain what happens upon success or failure, whether the tool requires specific permissions, or how it behaves if the permission doesn't exist. The minimal description leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (tag, user, permission) are fully described in the schema with clear descriptions and an enum for permission. The description adds no extra parameter meaning or formatting hints. With 100% schema coverage, a baseline score of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a user permission from a tag.' uses a specific verb ('Remove') and clearly identifies the resource (user permission) and target (tag). It distinguishes well from sibling tools like edubase_get_tag_permission and edubase_post_tag_permission, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or distinguish itself from other delete_permission tools for different entities (e.g., edubase_delete_exam_permission). An agent would need external knowledge to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, so the description need not restate that this is a safe read operation. The description adds that it lists 'all' attached tags, implying a full collection, but it does not provide additional behavioral context such as whether pagination is involved, whether tags are sorted, or potential authorization requirements. Given the annotations cover the safety profile, the description adds moderate value but not much beyond its literal statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or repetition. It immediately states the action and resource, making it easy for the agent to parse and act on. The word count is minimal and every word carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and the presence of an output schema (which likely specifies the return shape), the description is reasonably complete. It lacks usage guidance and does not address edge cases like empty classes or permission constraints, but those may be understood from the output schema and the API context. For a simple list operation, it covers the necessary information to invoke the tool correctly; however, a mention of whether the list is paginated or the expected output format would place it at a perfect 5. Overall it is good but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'class' with a descriptive note ('class identification string'), providing 100% coverage. The description neither adds nor clarifies the parameter's syntax or format beyond what the schema states. Since the schema already documents the parameter meaning and the description does not add alternative valid values or usage nuances, this is at the baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all attached tags of a class' clearly states the action ('List') and the resource ('tags of a class'), making the tool's purpose unambiguous. It is distinct from other tag-related siblings such as edubase_get_tags (all tags) and edubase_get_class_tag (a single tag), though it doesn't explicitly name those alternatives. It differentiates through its wording and the schema requires a class identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions like 'use when you need all tags for a class' or exclude cases where the user should instead use edubase_get_tag or edubase_get_class_tag. An agent would need to rely on the tool name and schema to infer appropriate usage, whereas a short usage note (e.g., 'prefer this over get_tags when you need a class''s tag set') or mention of pagination would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds no new behavioral context beyond what the annotations convey, such as whether partial matches are possible or what happens on non-existent event/tag. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the key information. It has no wasted words, but could potentially include a tiny bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of this check tool (2 required parameters, output schema present), the description is minimally sufficient. However, more details about return format or edge cases (e.g., boolean result vs error) would improve completeness, though the output schema may compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('tag identification string', 'event identification string'). The description does not add meaning beyond what the schema provides, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('check') and the resource ('tag attached to an event'). It distinguishes from sibling tools like edubase_post_event_tag (create) and edubase_delete_event_tag (delete), making the read-only nature of this tool obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use get_event_tags to list all tags vs this for checking a specific association). No exclusions or context about prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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=true. The description adds no further behavioral context, but does not contradict annotations. With strong annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence without any unnecessary words. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema exists), the description is mostly complete. Could mention that it retrieves branding for a specific exam, but it is sufficient for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a single parameter described as 'exam identification string'. The description adds no additional meaning beyond the schema. Baseline score of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'exam branding configuration'. It is distinct from sibling tools like edubase_get_exam, though it lacks explicit differentiation. Still, the purpose is well-understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like edubase_post_exam_branding for creating branding. The description does not mention prerequisites or context for usage.
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=true, so the agent knows it's a safe read operation. The description does not add any behavioral info beyond what annotations provide (e.g., no mention of output format or potential edge cases). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and wastes no words. However, for a tool with many siblings, a slightly more informative opening could improve usability without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an output schema exists (presumably documenting return values), the description does not hint at what the output represents (e.g., boolean or permission details). Given the 3 required parameters and the existence of many similar permission tools, the description is minimally acceptable but leaves some context for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all three parameters (integration, user, permission) have descriptions in the schema, including the permission enum. The tool description adds no further semantic detail about parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if a user has permission on an integration' uses a specific verb ('Check') and resource ('integration'), clearly distinguishing this read-only permission check from sibling tools like edubase_post_integration_permission (set permission) and edubase_delete_integration_permission (remove permission), as well as from similar tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 post or delete permission variants, or why one might choose this over permission checks for other entity types. With dozens of sibling permission tools, explicit 'when to use' or 'when not to use' instructions are missing.
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, covering the safety profile. The description adds no behavioral detail beyond what annotations provide, but it does not contradict them; the operation is a simple list, so no extra disclosure is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for a simple read-only list operation and front-loads the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with rich annotations, a complete input schema, and an output schema present, the one-line description is nearly sufficient. However, it lacks differentiation from related sibling tools, which slightly reduces completeness in a large tool namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (page, limit, search) are already documented. The description adds no additional meaning or context for parameters, maintaining 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb 'List' and resource 'organizations', with scope 'owned and managed'. It distinguishes from singular 'edubase_get_organization' implicitly, though it does not explicitly name alternatives or clarify nuances like owned vs managed versus all accessible 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as edubase_get_user_organizations or edubase_get_organization. The description provides no conditions, exclusions, or alternative routing, leaving the agent to infer applicability.
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, which cover the safety profile. The description adds no further behavioral details such as error conditions, whether an unknown organization raises an error, or any relationship to tag resources. Given the strong annotation coverage, this is adequate but lacks extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loads the action 'List', and contains no unnecessary verbiage. It is well-structured for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only list operation with an output schema and comprehensive annotations, the description conveys the essential function and scope. It could be improved by explicitly differentiating from similar sibling tools, but overall it is nearly complete given the low complexity and rich structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single 'organization' parameter with 'organization identification string'. The description adds the context that tags belong to that organization, but does not specify formats, accepted values, or how to find a valid identifier. With 100% 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all attached tags of an organization'), distinguishing it from global tag listing or singular tag retrieval through the use of 'all' and 'of an organization'. However, it does not explicitly name or contrast sibling tools, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as edubase_get_organization_tag, edubase_get_tags, or other entity-tag listers. It also omits prerequisites like how to obtain a valid 'organization' identifier. No context, exclusions, or alternative suggestions are given.
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 (readOnlyHint, idempotentHint), the description adds useful context by explaining the hierarchical position and hinting that full details are obtained via export, implying this tool returns limited data. This helps the agent understand the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, context, and guidance. It is front-loaded and avoids redundancy. However, the third sentence somewhat distracts from the primary purpose, reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description gives basic usage context (hierarchy, limitation) but does not detail what the tool returns or how it behaves beyond 'check existing'. The output schema likely compensates, but the description could be more self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter clearly defined as 'external unique question identifier'. The description does not add any additional meaning or format guidance, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check existing question' as the primary action, but the subsequent redirection to use the export function for details introduces ambiguity about the tool's actual purpose. It is distinct from 'get' siblings but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_get_questions or edubase_get_question_id. The mention of using the export function for details indirectly suggests this tool is for quick checks, but no clear when-not or alternative naming.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'owned and managed' scope filter, which is helpful context beyond the annotations. It doesn't describe return format or pagination behavior, but the output schema is present and annotations sufficiently cover the behavioral contract, so the extra context is adequately handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences. The first states the primary action and scope, the second defines the entity. Every sentence adds value with no filler, repetition, or unnecessary detail. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (though not shown), a fully documented parameter schema, and comprehensive annotations (read-only, open-world, idempotent, non-destructive), the description is sufficient for calling the tool correctly. It clarifies the resource type and hierarchical position. The only minor gap is lack of explicit mention of pagination, but this is covered by the parameters and output schema, so it's not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON schema provides 100% documentation coverage for all three parameters (page, limit, search) with clear descriptions. The tool description adds no additional parameter semantics beyond what the schema already states. Therefore, the default score of 3 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('owned and managed Quiz sets'), making the tool's purpose clear. It also explains what Quiz sets are (named collections of questions, middle level of hierarchy), which adds conceptual context. It doesn't explicitly differentiate from sibling tools like edubase_get_quiz or edubase_get_questions, but the plural 'Quiz sets' and the ownership scoping distinguish it adequately for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other siblings. It does not mention alternatives (e.g., get_quiz for a single quiz, get_quiz_settings for settings) or conditions under which this listing is appropriate. The only hint is 'owned and managed', but that's more of a scope definition than usage guidance. Given many sibling tools in the list, explicit routing is missing.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context beyond what these annotations provide. There is no mention of return format, error handling, required permissions, or side effects. The description does not contradict annotations, but it also does not add value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately short and front-loaded with the tool's purpose. It could be slightly improved by adding a `(read-only)` or similar context, but it is efficient for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 3 required parameters and an output schema exists, the tool is relatively simple. The description is adequate for a simple read-only check. However, it does not explain what the output looks like (the output schema is not shown but exists) or mention the boolean nature of the check. The description is minimally complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already describes all parameters adequately. The description does not add any additional meaning beyond what the schema provides. The baseline score is 3 because the schema is complete; the description adds no extra context here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks if a user has a specific permission on a quiz. The verb 'check', resource 'user', and object 'quiz' are present. However, it does not differentiate from sibling permission-checking tools (e.g., edubase_get_exam_permission, edubase_get_class_permission), relying on context from its name. This is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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. There are numerous sibling permission-checking tools (get_exam_permission, get_class_permission, etc.), and the description does not explain when to use this one (e.g., only for quizzes, not for exams). Since the sibling names are distinct and the description mentions 'quiz', usage is implied 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?
The description is consistent with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) and does not suggest any write or destructive effect. It adds little context beyond those annotations, such as prerequisites or return behavior, but there is no annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly names the action and subject with no redundant wording. It is front-loaded and immediately scannable, making it highly efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with a clear schema and output schema, the description provides sufficient information to invoke it correctly. It falls short only by not clarifying the relationship to similarly named sibling tools or defining what 'Quiz set' specifically means, but these gaps are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'quiz', is described in the input schema as 'Quiz identification string'. Since schema description coverage is 100%, the description adds no additional meaning to the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read operation ('get') targeting a distinct resource ('settings of a Quiz set'). It distinguishes the tool from broader retrieval operations like edubase_get_quiz, though it does not explicitly name that sibling or explain 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool over related alternatives such as edubase_get_quiz or the settings-modifier tools (edubase_put_quiz_settings, edubase_patch_quiz_settings). The intended usage context must be inferred entirely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, so the safety profile is clear. The description adds no behavioral details beyond the annotation-level information, and does not contradict any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, and directly front-loaded with the action and resource. Every word is meaningful and there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only operation with one well-documented parameter and an output schema available, the description is adequate. It lacks explicit usage context or distinction from siblings, but the minimal complexity means the provided information is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'quiz' parameter described as 'Quiz identification string'. The description adds no extra parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb ('Get') and resource ('skills defined in a Quiz set'), conveying the tool's function. It is distinguishable from similar tools like edubase_get_exam_skills by explicitly mentioning Quiz, but lacks any additional clarifying context about the nature of 'skills'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as edubase_get_exam_skills or other quiz-related getters. The description gives no context about prerequisites, nor does it mention exclusions or conditions for selecting this tool.
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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which inform the agent this is a safe, read-only operation. The description does not add any behavioral details beyond these annotations, such as whether permissions are inherited or how thresholds are evaluated. It is not contradictory, but it does not enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of 8 words with no fluff. It front-loads the core action and resource. While it could potentially include more context without becoming verbose, it is not overly long or redundant, achieving good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description is complete enough for basic identification. However, it lacks contextual details such as whether the check is for direct or inherited permissions, how to interpret the permission enum values in relation to user roles, or any error conditions. These gaps could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage), though they are minimal (e.g., 'tag identification string'). The tool description does not elaborate on parameter meaning, expected formats, or relationships between parameters, so it adds no additional value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 tag' uses a specific verb ('Check') and identifies the resource clearly ('user permission on a tag'). Among sibling tools, it distinguishes itself from similar permission checkers for other resources (e.g., edubase_get_class_permission) and from mutation tools like edubase_post_tag_permission, providing clear purpose 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/5Does 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, no prerequisites or limitations, and no mention of what to check before invoking. For example, it does not clarify that this tool should be used to verify a user's permission level before attempting a tag modification, nor does it warn against using it for other permission types.
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, so the safety profile is fully covered. The description adds the membership-relationship semantic (classes the user belongs to, not owns or administers), but discloses nothing about pagination, empty results, or whether archived/inactive classes are included. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler: 'List all classes a user is member of.' Every word earns its place, and the size is appropriate for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with full annotations and an existing output schema, the description covers the essential query semantics. Minor gaps like return-behavior edge cases and empty-result handling are not critical given the output schema and annotations carry much of the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the single required 'user' parameter is already documented in the schema as 'user identification string'. The description adds no further parameter semantics such as identifier format or accepted value types, so the baseline score of 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names both the resource and scope ('classes a user is member of'), making the query direction clear as a membership lookup. However, it does not explicitly differentiate itself from closely related siblings like edubase_get_user_group, edubase_get_user_organizations, or edubase_get_class_members, so it stops just short of full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as edubase_post_user_classes, edubase_delete_user_classes, edubase_get_class_members, or edubase_get_user_group. With dozens of related sibling tools present, the agent is left to infer the appropriate selection context on its own.
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 (readOnlyHint=true) already signal safety. The description adds clarity on searchable fields (email, username, code) beyond annotations, but does not detail behavior like partial matches, case sensitivity, or handling of multiple results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that delivers the essential purpose without extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, the description lacks details on search semantics (e.g., exact vs. partial match, handling of multiple or zero results) and does not leverage the openWorldHint annotation nor confirm if it returns a single user or list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'query'. The description adds meaning by specifying that the query can be an email, username, or code, which is not present in the schema description ('query string'). This compensates for the minimal schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lookup user by email, username or code', specifying the verb (Lookup), resource (user), and search fields. However, it does not explicitly distinguish from sibling tools like edubase_get_user or edubase_get_user_name, though the search-oriented phrasing implies 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/5Does 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_get_user for exact ID lookup, edubase_get_users for listing). No context about prerequisites or exclusions is given.
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 provide readOnlyHint=false and destructiveHint=false, which already indicate this is a mutation (create) operation without destruction. The description confirms this by stating 'Create new permission,' which matches the annotations. It does not add further behavioral details beyond what annotations provide, such as whether the operation is idempotent (idempotentHint=false is already in annotations), or what happens if the permission already exists. Since annotations already cover the basic behavioral profile, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no unnecessary words. It is front-loaded with the key verb 'Create' and specifies the resource. While it is brief, it does not waste any space. A slightly more detailed sentence could be beneficial, but the conciseness is commendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a medium complexity (3 required params, 1 enum), and both schema and output schema are provided, the description is minimally adequate. It covers the basic purpose but does not explain the return value (output schema exists), the effects of different permission levels (e.g., what 'admin' vs 'view' entails), or potential side effects (e.g., overriding existing permissions). With no output schema description required and good schema coverage, a score of 3 reflects a complete but bare-bones description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as all three parameters (user, event, permission) have descriptions in the input schema. The description does not add any additional parameter semantics beyond what the schema already provides. The parameter descriptions are clear: 'user identification string', 'event identification string', and 'permission level' with an enum list. The description could have clarified the relationship between parameters (e.g., that the permission is granted to a user for a specific event), but this is already implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new permission for a user on an event, using specific verbs ('Create') and resource ('permission for a user on an event'). It effectively distinguishes itself from sibling tools like edubase_delete_event_permission and edubase_get_event_permission, but the description is brief and could be more specific about the scope of 'permission' (e.g., it could mention the permission levels available).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It does not specify when to use it versus alternatives like edubase_post_event_transfer (which might transfer permissions) or the various get/delete permission tools. Since there are multiple permission-related tools (e.g., edubase_post_class_permission, edubase_post_exam_permission), the context is implied but not explicitly stated. No when-not-to-use or alternative conditions are given.
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=false, destructiveHint=false, and idempotentHint=false, so the description adds value by noting that it updates existing memberships, implying it can modify permissions of current members. It does not contradict annotations. This behavioral detail is useful beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, direct, and front-loaded with the main action. It efficiently conveys the core purpose and a key behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 3 with enums, and no output schema, the description is adequate but could benefit from noting that the tool returns some confirmation or list of assigned users. It also doesn't mention permission defaults or that notify is optional. Passable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds no further semantics beyond the schema details. Baseline score of 3 is appropriate as the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Assigns user(s) to organization(s)' and includes the update behavior ('Updates memberships if already member of an organization'). This distinguishes it from sibling tools like edubase_get_organization_members and edubase_delete_organization_members, but does not explicitly contrast with those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as edubase_post_user_organizations or edubase_delete_organization_members. The description mentions updates but doesn't clarify if this should be used for new assignments only or also for changing permissions. No exclusions or context about prerequisites are provided.
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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description does not add behavioral detail beyond what annotations provide—nothing about idempotency (can attaching the same tag twice cause duplicates?), side effects, or authentication needs. Given that annotations are present and minimally informative, the description adds no extra transparency, earning a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words, which is extremely concise and front-loaded with the action. It earns its place by stating the core functionality without waste. It could be slightly improved by including a note on usage context, but for brevity it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two string parameters, no enums, and an output schema (not provided to the evaluator), the description is minimally sufficient. However, it lacks any mention of what the output is (e.g., the created tag-video association), or important caveats like whether the operation fails silently if tag/video doesn't exist. The tool is simple, but the description could still be slightly more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level meaning beyond the schema's 'tag identification string' and 'video identification string'. It does not explain format, source (e.g., from edubase_get_tag), or constraints (e.g., length, allowed characters). No added value, but no deduction since schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach tag to a video' clearly states the action (attach) and the resources (tag and video). It distinguishes from sibling tools like edubase_get_video_tags (list), edubase_delete_video_tag (remove), and other post_tag tools for different entities (class, course, exam, etc.), though it could explicitly differentiate from edubase_post_event_tag or edubase_post_class_tag by stating 'to a video' more precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to associate a tag with a video, which is clear enough. However, it provides no guidance on when not to use it, prerequisites (e.g., tag must exist? video must exist?), or alternatives—for instance, using edubase_post_class_tag for class context or edubase_get_video_tags to check existing tags. The agent can infer context from the tool name and siblings, but explicit guidance is absent.
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 destructiveHint=true and idempotentHint=true. The description adds no further behavioral context (e.g., effect of removing non-existent users, permission requirements). It is not contradictory but adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple parameterized delete operation but lacks information about return values (no output schema). Given the minimal description and no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes users from a class, using a specific verb and resource. It distinguishes from siblings like edubase_delete_class_permission (which removes permissions) and edubase_post_class_members (which adds users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., edubase_delete_user_classes for removing a user from all classes). The description only states the action without providing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 no additional behavioral context (e.g., what happens if no branding exists, permission requirements, reversibility). It is adequate but not informative beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter and no output schema, the description is minimally sufficient. However, it lacks details on edge cases (e.g., non-existent branding) and prerequisites, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'exam' with description 'exam identification string', covering 100% of parameters. The description does not add any extra meaning or constraints beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove branding from an exam' uses a specific verb ('Remove'), identifies the resource ('branding'), and clearly distinguishes from sibling tools like edubase_delete_exam (deletes entire exam) and edubase_post_exam_branding (adds branding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., edubase_delete_exam, edubase_post_exam_branding). There is no mention of prerequisites, idempotency, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description carries a lower burden. The description adds no extra behavioral context (e.g., effect of removing a non-existent tag, side effects, or reversibility). It is adequate but adds no value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is concise but could be slightly expanded to include usage guidelines or behavioral notes without losing brevity. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no enums, output schema present), the description is sufficient for a basic understanding. However, it lacks guidance on when to use this specific delete tool among many similar siblings, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described as 'identification string'. The description does not add any additional meaning, format, or usage hints beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a tag attachment from an organization' uses a specific verb ('Remove') and resource ('tag attachment from an organization'), clearly distinguishing this tool from sibling tools like edubase_post_organization_tag (add) and other entity-specific delete_tag tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., edubase_delete_class_tag, edubase_delete_course_tag). The description does not mention when to use, when not to use, or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the context that removal can target a specific group, but it does not disclose other behavioral traits like whether removal is permanent or what happens to the question entity itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the action and scope with no redundant words. It is front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic operation, it lacks details about return values (no output schema), reversibility, or effects on dependent objects. For a destructive tool, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for each parameter. The tool description does not add further meaning, such as how to obtain the identifiers or the format required, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Remove' and the resource 'question(s) from a Quiz set, or one of its question group', which clearly distinguishes it from sibling tools like edubase_delete_question (which likely deletes the question entity entirely). The scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as edubase_delete_question or other delete tools. It does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the description's statement about deletion is consistent. However, it does not add significant behavioral context beyond what annotations provide, such as whether the link becomes immediately invalid or if there are any side effects. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the essential purpose without any extraneous words. It is optimally concise and front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects) and the presence of annotations, the description covers the basic functionality. However, it does not explain the effect (e.g., link becomes invalid, returns success) or any required context like needing the user ID. It is minimally acceptable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear explanations for both parameters ('user identification string' and 'generated login link to be invalidated'). The description does not add any extra meaning beyond the schema, so it meets the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('previously generated login link'). Among many sibling delete tools, this one is uniquely identified by targeting login links, distinguishing it from others like edubase_delete_user or edubase_delete_class_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention whether to use this over edubase_delete_user (which deletes the user account) or other delete tools. No context about prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, covering the safety profile. The description adds no further behavioral context (e.g., pagination behavior, what 'owned and managed' precisely includes) beyond the schema. It neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and resource. It earns its place by stating the core purpose economically, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and comprehensive annotations, the description is adequate for a simple list operation. However, it omits clarification on the 'owned and managed' scope and does not differentiate from sibling getters, leaving some contextual ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (page, limit, search). The description does not mention parameters at all, but with complete schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('classes') with a clear scope ('owned and managed'), distinguishing it from sibling tools like edubase_get_class (single class) or edubase_get_class_members (members of a class). It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as edubase_get_class or edubase_get_user_classes. It does not mention any exclusions, prerequisites, or conditions that would help an agent decide between similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, covering the safety profile. The description adds no extra behavioral context beyond restating the basic read operation. It 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no wasted words. It is concise and front-loaded with the action and target, though it lacks any additional detail that could aid selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only GET operation with one fully documented parameter, an output schema present, and annotations covering idempotency and safety, the description is sufficient. It does not explain what the autologin configuration includes, but that is not required given the output schema context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for the single parameter 'exam' with 'exam identification string'. The description adds no additional meaning beyond what the schema already states, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'automatic login configuration of an exam', clearly stating what the tool does. It distinguishes itself from sibling tools like edubase_post_exam_autologin and edubase_delete_exam_autologin by explicitly focusing on 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or why one would choose this over other exam-related getters such as edubase_get_exam_settings.
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 state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds little beyond 'owned and managed' scope. It does not disclose pagination defaults or that the search parameter is not used in search mode, which is actually mentioned in the schema rather than the description. The description 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the verb and resource. It earns its place and has no filler, but it is so minimal that it misses an opportunity to mention pagination or how the result set is scoped relative to the account/context. Still appropriate overall for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, read-only annotations, and schema descriptions for all three optional parameters, the description is reasonably complete for a straightforward paginated list operation. It does not explicitly distinguish the return shape or scope from sibling integration endpoints, and the 'owned and managed' phrase is the only contextual qualifier, leaving some ambiguity about what set of integrations will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented with descriptions for page, limit, and search. The description itself contributes the scope context ('owned and managed') and the schema adds operational details like 'not used in search mode!' and default values. This is slightly above baseline because the schema descriptions are informative and the tool description reinforces the meaningful filter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List owned and managed integrations' uses a clear verb and resource, and distinguishes itself from mutation tools like edubase_post_integration or edubase_delete_integration. While the phrase 'owned and managed' adds useful scoping, the description is concise but not fully differentiated from other list/get tools such as edubase_get_integration or edubase_get_integration_keys because it doesn't explain how 'integrations' here relates to those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only listing operation appropriate when you need all integrations for the current context. It does not explicitly state when to prefer this tool over edubase_get_integration, edubase_get_integration_keys, or the integration permission/tag tool variants. No exclusions or alternatives are named.
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=true. The description adds no additional behavioral context (e.g., whether membership includes nested groups, required permissions, or pagination). With annotations covering the safety profile, the description is adequate but does not provide extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It concisely states the tool's purpose with zero waste, earning the highest score in this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a list tool with an output schema (which likely documents return values), the description covers the basic purpose. However, it lacks completeness regarding potential pagination, filtering, or whether the list includes all fields. The openWorldHint suggests results may be partial, but the description does not clarify this behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add any meaning beyond what is already in the input schema (the parameter 'organization' is described as 'organization identification string'). No extra parameter details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all members in an organization' uses a specific verb (List) and clearly identifies the resource (members) and scope (in an organization). It effectively distinguishes this tool from sibling tools like edubase_post_organization_members (add members) and edubase_delete_organization_members (remove 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/5Does 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 such as edubase_get_class_members (for class members) or other organization-related tools. There are no explicit conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds 'owned and managed' scope but no extra behavioral details (e.g., pagination behavior or search mode). Meets baseline 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and concise. Every word serves a purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not shown; description is adequate for a simple list tool. However, it could mention that it returns paginated results or that search affects pagination. Slightly incomplete given the complexity of siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in schema. Description does not add additional meaning beyond schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description 'List owned and managed Quiz questions' clearly specifies verb (list), resource (questions), and scope (owned and managed, for quizzes). Distinguishes from siblings like edubase_get_question (singular) and edubase_get_quiz_questions (quiz-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_get_question_id or edubase_get_quiz_questions. Lacks context about prerequisites or when not to 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 indicate the tool is not read-only, not destructive, and not idempotent, but the description adds minimal behavioral context. It does not clarify whether users are appended or replaced, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is appropriately concise for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers basic intent, it lacks information on return values, idempotency implications (annotations: not idempotent), and whether the assignment is additive or overwriting. Given the simple schema and complexity, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters (exam and users), achieving 100% coverage. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Assign user(s) to an exam.' clearly states the specific action (assign) and resource (users to an exam). It is unambiguous and directly conveys the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like edubase_delete_exam_users. It does not mention prerequisites (e.g., exam must exist) or provide context for appropriate usage.
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 a non-read, non-destructive mutation. The description adds that it updates existing memberships, which is useful but still vague on specifics (e.g., how updates differ from initial assignments, permissions required). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The core action and an important nuance (updates existing membership) are front-loaded. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and update behavior, but with no output schema and 4 parameters, more detail on expected response or parameter effects (e.g., what 'notify' does, 'expires' behavior) would improve completeness. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description does not add any additional meaning or context beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Assign user to class(es)') and adds the update behavior detail, clearly distinguishing it from siblings like edubase_get_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/5Does 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_class_members, edubase_classes_members). No explicit when/when-not or trade-offs 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, idempotentHint=true, and readOnlyHint=false. The description adds minimal context beyond "remove a tag attachment", which is consistent but does not disclose additional behavioral details like what happens if the tag is not attached or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of only 6 words with no filler. Every word earns its place for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, existing annotations, and an output schema, the description is sufficiently complete. It clearly states the action and resource, though it could optionally mention idempotency (already covered by annotations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The tool description does not add any additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "remove" and resource "tag attachment from a class", clearly distinguishing from siblings like edubase_delete_course_tag or edubase_delete_class_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many sibling tag deletion tools (e.g., for courses, events, exams) and the description does not specify the context that differentiates them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's statement 'Remove' is consistent but adds no new behavioral insight. It does not disclose whether the operation is reversible, if the tag must already be attached, or any side effects. With the burden already lowered by annotations, the description contributes minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that immediately communicates the tool's action and target. There is no extraneous information, and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required string parameters, high schema coverage, an output schema present), the description is largely complete. It could optionally note that the tag must be currently attached to the course, but this is a minor gap. Overall, it sufficiently covers the operation for a straightforward deletion task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'course' and 'tag' have descriptions like 'course identification string'). The description adds no further parameter meaning beyond what the schema provides, so it meets the baseline for high coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a tag attachment from a course' uses a specific verb ('Remove') and clearly identifies the resource ('tag attachment') and context ('from a course'). This distinguishes it from sibling delete_*_tag tools which target other entities like class, exam, or event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the resource context ('course'), but it provides no explicit guidance on when to use this tool versus alternatives (e.g., delete_class_tag) nor any exclusions or prerequisites. The usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description restates the delete action but adds no new behavioral info beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough for a simple delete operation with annotations. However, the 'and/or' could be clarified (e.g., whether deleting both requires separate calls).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds no additional meaning beyond the schema for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (uploaded file and/or temporary file upload link). It is specific and distinguishes from other delete tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives, no prerequisites or context for usage provided. Simply states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and idempotentHint: true, informing the agent the tool is mutating but safe to retry. The description does not add behavioral context beyond this—it doesn't note, for instance, whether removing a permission cascades to sub-resources or requires specific user roles. With annotations covering the key traits, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose with no unnecessary words. It is appropriately front-loaded and easy to parse. A slightly longer description that included minor usage guidance (e.g., related tools) would still be acceptable, but the current version is lean and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, all string, no nested objects) and the presence of an output schema, the description is functional but lacks context about the permission removal process (e.g., what happens if the user doesn't have the permission, or if the permission is the last one). The sibling tools for post/get/delete are similar, so the description is minimally adequate but not enriched with situational nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (user, permission, organization). It does not explain the relationship between parameters or provide examples, but the schema already provides clear enum values for permission and basic descriptions for each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('user permission from an organization'), distinguishing it from sibling tools like edubase_post_organization_permission (which adds a permission) and edubase_get_organization_permission (which retrieves them). The verb and target are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating the tool removes a permission, but it does not provide guidance on when to use it versus alternatives (e.g., it does not mention that to add a permission, one should use edubase_post_organization_permission, or that the permission must already exist). No explicit exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, so the description does not need to restate that. The description adds no additional behavioral context (e.g., what happens to the SCORM material, required permissions, or error states). With annotations already covering the destructive nature, the description's minimalism is acceptable but misses an opportunity to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core action and resource. It is front-loaded and efficient, with no unnecessary words. However, it is so brief that it could benefit from a tiny bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema, return values need no explanation. The tool has only two simple required parameters and no enums or nested objects. The description, combined with the schema and annotations, is minimally complete for a basic deletion operation, but additional context about prerequisites or side effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters ('scorm' and 'tag') are fully documented in the schema with their descriptions ('SCORM identification string', 'tag identification string'). The description adds no further parameter context beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a clear resource ('tag attachment from a SCORM learning material'). It accurately distinguishes from siblings like edubase_get_scorm_tag (read) and edubase_post_scorm_tag (create), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tag tools. Usage context is only implied by the tool's name and description, which is adequate for a straightforward remove operation but lacks differentiation from other tag deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide strong behavioral cues: destructiveHint=true clearly indicates a destructive/mutating operation (removing a tag), idempotentHint=true suggests it can be safely retried, readOnlyHint=false confirms it modifies state, and openWorldHint=true hints that the object is not fully enumerable. The description and annotaions are consistent. Although the description does not elaborate further, the annotations carry the transparency burden effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 6 words, which is efficient but borders on under-specification. Every word serves a purpose, but the sentence is structured as a fragment ('Remove a tag attachment from a video.'). It is front-loaded and readable, but could be slightly more complete (e.g., including the resource ID or context) without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no enums, no nested objects) and the presence of an output schema and annotations, the description is minimally adequate. However, it does not specify what happens on success (e.g., returns void or confirmation), nor does it mention if the operation is reversible. The agent might benefit from knowing the response format or side effects, but the annotations partially compensate for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the schema already documents both parameters (tag and video) with descriptions. The tool description adds no extra meaning beyond the schema, and there are no enums or nested objects. Per the guidelines, when coverage is high (>80%), baseline is 3 even without additional param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'tag attachment from a video', which precisely differentiates this from sibling tools like edubase_post_video_tag (which adds a tag) and edubase_get_video_tag (which reads). The sibling list contains many tag-related tools for different entities (class_tag, exam_tag, etc.), so the explicit mention of 'video' and 'tag attachment' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, the sibling tools include edubase_get_video_tags (list tags) and edubase_post_video_tag (add tag), but the description does not advise that this tool is for removal only, nor does it mention any prerequisites (e.g., the tag must already be attached). An agent would need to infer usage from the action name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation and non-destructive behavior. The description adds the prerequisite of requesting a link in advance but does not disclose file size limits, overwrite behavior, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys the core purpose and one key prerequisite. Slightly awkward phrasing ('with a link requested from the API in advance') but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains input well but lacks any mention of output or return value. Without an output schema, the AI is left guessing what the tool returns. Adequate for a basic upload operation but missing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already exist. The description adds no significant new meaning beyond the schema, only restating that source can be local file or URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Upload a local file or a file from a URL to the EduBase temporary file storage', specifying the action and target. It also mentions the prerequisite of having a filebin URL, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies that a filebin URL must be obtained beforehand but does not explicitly compare to sibling tools like edubase_post_filebin_upload. No 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the scope that it lists 'ALL' assignments, implying no filtering, but does not disclose additional behavioral details such as pagination, ordering, or whether only active assignments are returned. Given the strong annotation coverage, the description's contribution is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'List all assignments in a class.' It contains no unnecessary words, is front-loaded with the action, and is easy to parse. Every word contributes to clarifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation with an output schema present, this description is largely complete. It tells an agent exactly what the tool does, and the output schema can provide return value details. However, it does not cover edge cases or contextual information (e.g., whether archived or finished assignments are included), which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the single required parameter 'class' is described as 'class identification string'. The description adds no further semantic detail about the class parameter beyond the context of 'in a class'. Since schema coverage is complete, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all assignments') and the resource ('in a class'). This distinguishes it from sibling tools like get_class, get_class_members, and get_quiz_questions, which deal with different resources. The verb+resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives. It does not mention the prerequisite of having a valid class identifier, nor does it explain any distinguishing scenarios (e.g., retrieving all assignments vs. filtering by user). This leaves an agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it is a safe read operation. The description adds minimal behavioral context beyond stating it lists 'all' members, but does not disclose details like pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded and efficient, clearly stating the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, with annotations) and the presence of an output schema, the description is adequate. It does not need to explain return values as the output schema covers that. However, a brief mention of what 'members' means could improve clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter description 'class identification string'. The description does not add any new meaning beyond what is in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and resource (members) with a clear scope (in a class). It clearly distinguishes from sibling tools like edubase_get_class (class details) and edubase_get_class_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like edubase_post_class_members for adding members or edubase_get_class for class details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds no additional behavioral context (e.g., output format, error behavior). Since annotations carry the burden effectively, a baseline score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and the existence of an output schema, the description is largely complete. It could be slightly more explicit about the return type (e.g., 'returns a boolean'), but the output schema likely covers that. The description is adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'course' and 'tag' have descriptions in the input schema). The description 'Check if tag is attached to a course' adds no extra semantic meaning beyond what the schema already provides. Baseline 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if tag is attached to a course' uses a specific verb ('Check') and a clear resource ('tag attached to a course'). It effectively distinguishes this tool from siblings like 'edubase_get_course_tags' (list all tags), 'edubase_post_course_tag' (attach), and 'edubase_delete_course_tag' (detach) by indicating an existence check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. For example, it does not mention that this tool is for checking a single tag's existence, while 'edubase_get_course_tags' should be used to list all tags. No when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, so the safety profile is covered. The description adds no extra behavioral context (e.g., behavior for nonexistent events, pagination, or ordering), which is acceptable given the simple read-only nature and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear and free of any filler. It earns its place and communicates the core function immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only list operation with annotations and an output schema, the description is adequate. It could optionally mention edge cases (e.g., empty event), but nothing essential for calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'event' parameter is described as 'event identification string'). The description does not add further meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('attached tags of an event'), clearly distinguishing it from sibling tools like edubase_get_event_tag (singular) and mutation tools like edubase_post_event_tag. It unambiguously conveys the 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/5Does 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, such as edubase_get_event_tag for a single tag or other tag-listing tools. The context of use is left entirely to inference from the name and 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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only hierarchical context (built from Quiz sets), which does not reveal new behavioral traits beyond the annotations. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant wording. The core action is front-loaded, and the hierarchical context is supplementary and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, complete parameter descriptions, and an output schema, the description adequately supports a list tool. Minor gaps exist, such as no mention of pagination or how 'owned and managed' scoping works, but these are unlikely to block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (page, limit, active, search) are well-documented in the schema itself. The description adds general context about owned/managed exams but does not enrich parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (List) and resource (owned and managed exams), and adds context that exams are the highest level in the hierarchy built from Quiz sets. This distinguishes it from single-exam retrieval tools like 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as edubase_get_exam (which retrieves a single exam). The description does not mention search mode, pagination, or filtering, leaving the agent to infer usage from the name.
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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, making the tool's safety profile clear. The description does not add behavioral context beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, simple output), the description is sufficiently complete. It could benefit from mentioning the output format, but the presence of an output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, which already includes a description ('question identification string'). The description adds minimal value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (external unique question identifier) along with the input (question identification string). It distinguishes the tool from siblings like edubase_get_question which retrieve full question objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as edubase_get_question or edubase_get_questions. The description lacks explicit context for when it is appropriate.
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's 'Get' aligns. The description adds no additional behavioral context beyond what annotations provide, but it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of six words that efficiently conveys the purpose without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, presence of output schema, and annotations, the description is sufficient for an agent to understand basic usage. It could mention that the play ID is required, but that is implied by the schema's required field.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already describes the 'play' parameter as 'Quiz play identification string'. The description adds no extra meaning or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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'. It distinguishes from related quiz tools like get_quiz_results_user (user-level results) and get_quiz (general quiz info) by specifying a 'specific Quiz play'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_quiz_results_user or get_quiz. It does not mention prerequisites or scenarios where this tool is preferred.
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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description does not add additional behavioral details beyond what is implied by 'Check'. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence conveying the tool's purpose without unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required parameters, read-only check with output schema present), the description captures the essential behavior. However, the exact return format is not described (though output schema may cover it).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not elaborate on parameters beyond the schema’s own descriptions. While the parameters are self-explanatory, the description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if a user has permission on a SCORM learning material.' It uses a specific verb ('check') and resource ('permission on SCORM'), and distinguishes from sibling tools like 'edubase_delete_scorm_permission' and 'edubase_post_scorm_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the many sibling tools for checking permissions (e.g., for classes, courses, etc.), the agent would benefit from explicit context, but none is provided.
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 states the tool checks for attachment, which is consistent with readOnlyHint annotation. Annotations already indicate non-destructive, idempotent behavior. The description adds no additional behavioral context beyond confirming it is a read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary information. Efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple existence check, the description is mostly complete. Output schema exists to define return values, so description need not elaborate. However, it could briefly mention that the result indicates presence or absence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no new meaning beyond the schema descriptions. Baseline of 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('check') and the resource ('if tag is attached to a SCORM learning material'). It distinguishes from siblings like edubase_get_scorm_tags (retrieves all tags) and edubase_delete_scorm_tag (removes 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/5Does 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. There is no explicit mention of when to check existence versus retrieving all tags or deleting. The sibling list includes related tools, but the description does not contextualize usage.
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 and idempotentHint, so the safety profile is clear. The description adds that it returns the 'latest valid' login link, implying recency and validity filtering, which is useful beyond the annotations. However, it does not explain potential edge cases (e.g., behavior when no valid link 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, front-loaded with the core action. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one input, one output) and the presence of an output schema to explain return structure, the description adequately covers retrieval of the latest valid login link. It could mention error handling or the nature of the link (e.g., URL), but the output schema likely fills gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (user is described as 'user identification string'). The description does not add further meaning to the parameter, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest valid login link for a user. It uses a specific verb-resource combination and distinguishes itself from sibling tools like edubase_get_user (user info) and edubase_post_user_login (creates a login link).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that edubase_post_user_login should be used to create a new login link. The description only states what it does, not when it is appropriate.
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 a specific rule ('Global presets cannot be modified') on top of the annotations, which already indicate non-destructive and idempotent behavior. Since annotations cover the general safety profile, this extra rule provides additional context but does not describe other behaviors like response format or side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of two short sentences. It is front-loaded with the action and resource, and the exclusion is stated directly. No fluff or redundancy, though it could be slightly more informative about parameter behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully described schema and an output schema present, the description is sufficient for an agent to call the tool correctly. The key limitation is captured, and the rest of the behavior is outlined by annotations. Still, it lacks any note about the type immutability rule (which is in the schema, so not a gap here) or about how updates are applied; the overall context is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing each parameter (type, title, grades, preset, language) with its own documentation. The description itself adds nothing beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Update') and a specific resource ('existing custom grading preset'), and immediately distinguishes from the global preset case. It makes clear this is the patch operation for grading presets, differentiating from sibling tools like post (create) and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when this tool applies (existing custom grading preset) and an explicit exclusion (global presets cannot be modified). However, it does not name alternative tools (like post for creation) or give guidance on when to prefer this over them, leaving some inference needed.
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=false and destructiveHint=false; the description adds the feature-flag prerequisite, which is helpful behavioral context. However, it does not disclose what the response looks like or any side effects (e.g., whether creating an existing title fails), which would be valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and then a key prerequisite. No waste, and the critical information is conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema with full parameter documentation and an output schema, the description covers the essential context. The main missing piece is a hint about the available 'type' values or cross-referencing to the GET/PATCH siblings, but this is minor for a create operation with detailed schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented with type-specific constraints. The description adds no additional parameter-level meaning beyond what the schema already explains, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create') and resource ('grading preset'), which is distinct from the sibling verbs patch, delete, get. However, the word 'custom' could be misleading because the 'type' parameter supports several non-custom types (hungarian-school, hungarian-university). Minor ambiguity prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful prerequisite ('Needs the custom grading feature to be enabled'), but does not explicitly state when to use this tool versus the siblings (patch, delete, get) or exclude alternatives. Usage context is only implied by 'create'.
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 that this is not read-only, not idempotent, and not destructive. The description adds that it creates a distinct new account, but it does not surface side effects such as automatic password generation, email/SMS notification when notify is set, or behavior when a username/email already exists. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word carries the operation and resource, which is ideal for a tool whose parameter details are fully captured in its schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter write operation, the one-line description is lean, but completeness comes from the accompanying schema: required fields, default password, notification, and valid values are all defined, and an output schema is present so return value details do not need to be in the description. It could be strengthened by naming sibling endpoints for lifecycle handling, but the core decision context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Because schema_description_coverage is 100%, the schema already documents all 19 parameters including defaults, enums, lengths, formats, and the custom object behavior. The description itself adds no parameter-level details, so the standard baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and a specific resource ('new EduBase user account'). This clearly distinguishes from sibling user operations like edubase_get_user, edubase_patch_user, and edubase_delete_user, so an agent can infer this is the provisioning 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this over related user endpoints, no prerequisites such as required permissions or uniqueness constraints, and no mention that existing accounts should be handled with edubase_patch_user or edubase_delete_user. The only usage signal is the verb 'Create', which restates the tool's purpose rather than offering routing 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 explains that existing valid links are reused, indicating idempotency-like behavior. However, annotations set idempotentHint=false, creating a contradiction. No details on authorization, rate limits, or side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence states the purpose directly; second sentence clarifies a key behavioral trait. Maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return values. It adequately covers the core behavior and references the link reuse behavior. However, it could briefly mention that this is for authentication or that it's a POST operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all seven parameters described in the schema. The description adds no extra parameter-level meaning or interaction details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate login link', specifying the verb and resource. Among siblings, this tool is distinct as the only one for creating/retrieving login links, with edubase_get_user_login and edubase_delete_user_login covering retrieval and deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_user_login or other authentication methods. No mention of prerequisites or 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 indicate non-destructive (destructiveHint=false) and open world (openWorldHint=true). The description adds 'Update' confirming mutation, but no further behavioral details (e.g., partial update behavior, idempotency). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and presence of an output schema, the description is mostly complete. However, it could mention that the user must exist or that the operation is a full replacement of name fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description adds no additional meaning 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a user's name.' clearly states a specific verb (update) and resource (user's name), and the tool name aligns. It distinguishes from siblings like edubase_patch_user (general update) and edubase_get_user_name (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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives (e.g., edubase_patch_user for other fields) or prerequisites (e.g., user existence).
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 already declare destructiveHint=true and idempotentHint=true. The description adds little beyond that. It does not clarify what happens to dependents, whether the user must still exist, or that the operation is irreversible. For a destructive tool, more behavioral context would be valuable, but the annotation covers the basic intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of only 5 words, perfectly front-loaded, and contains zero filler. Every word serves a purpose: 'Remove' conveys the action, 'user permission' the target, and 'from an exam' the scope. This is maximally concise while still being complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage, an output schema present, and annotations clarifying destructive/idempotent behavior, the description is adequate for a straightforward delete operation. It could optionally mention that this mirrors a sibling 'post_exam_permission' or that the permission value must match an existing assignment, but the essential information is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having clear descriptions. The description verb 'Remove' adds the context that this is a deletion operation, which is consistent with the parameters (exam, user, permission). No additional parameter semantics are needed beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and clearly identifies the resource as 'a user permission from an exam.' This directly distinguishes it from siblings like 'edubase_post_exam_permission' (add permission) and 'edubase_get_exam_permission' (list permissions), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool involves removing a permission, and the destructiveHint annotation implicitly warns about potential impact. However, the description does not explicitly state when to use this tool over alternatives (e.g., editing permissions via post_exam_permission) or any prerequisites (like the exam must exist). The agent gets the basic action but lacks context on appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds context about the data source (Quiz set used by an exam), which is useful but does not disclose return format, pagination, or failure behavior. It provides some value beyond annotations but not a rich behavioral overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the essential function without any filler. It is front-loaded with the action and resource, and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with one well-documented parameter, an output schema present, and annotations indicating safe behavior, the description is adequately complete. An agent has all necessary cues to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'exam' is 100% covered ('exam identification string'), so the baseline is 3. The description adds no additional parameter details or format hints 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('skills defined in the Quiz set used by an exam'), distinguishing it from related tools like edubase_get_quiz_skills or edubase_get_exam_settings. It explains the indirect relationship between exam and quiz set, leaving no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any sibling tools, edge cases, or prerequisites. The intent is implied from the name and description, but there is no explicit direction for an agent to choose this over edubase_get_quiz_skills or other getter 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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no contradictory or additional behavioral context (e.g., no mention of return format or side effects). Since the annotations are comprehensive and consistent, the description's minimalism is acceptable — it doesn't need to restate safety. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence (11 words) that packs the primary purpose. It is front-loaded and efficient. However, it could be improved by adding a brief note on usage distinction (e.g., 'Unlike get_exam_tags, returns a boolean') without becoming verbose. Current conciseness is good but not exceptional given the lack of differentiating guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 string params, no enums, no nested objects, has output schema), the description is largely complete. The annotations cover safety (read-only, idempotent), and the schema describes inputs. The only gap is that the description doesn't mention the output (likely a boolean indicating presence), but the presence of an output schema means that information resides elsewhere. Thus, for a simple existence check, the description meets most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 100% description coverage ('exam identification string', 'tag identification string'); the description adds no further meaning beyond those labels. According to the rubric, when schema_description_coverage is high (>80%), the baseline is 3. The description does not elaborate on format, examples, or constraints (e.g., how to obtain these IDs). Thus, score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a tag is attached to an exam (verb 'check' + resource 'tag-exam association'). This is sufficiently specific. However, among sibling tools like edubase_get_exam_tags (which presumably lists all tags for an exam), edubase_post_exam_tag (which attaches a tag), and edubase_delete_exam_tag (which removes one), this tool's purpose as a 'check' (existence/boolean test) is distinct but not explicitly contrasted. The title also repeats the description verbatim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a conditional usage scenario: one would use this before deciding to add or remove a tag (to verify existence first). However, no explicit guidance is provided on when to use this tool versus, say, edubase_get_exam_tags (which might return all tags) or edubase_post_exam_tag (to attach). Sibling tools exist for those operations, so a note on when this check is beneficial could elevate the score. Without exclusions or alternatives, the usage context is only weakly implied.
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, destructiveHint, idempotentHint, and openWorldHint. The description adds no behavioral context beyond the purpose; it does not explain how results are returned 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is appropriately sized for a simple tool, though it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, presence of annotations, and existence of an output schema, the description is adequate. It covers the essential purpose, though it omits details about what 'results' entail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the object (user results), and the scope (specific Quiz set). It is specific and distinguishes from sibling tools like edubase_get_quiz_results_play and edubase_get_exam_results_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the name implies it is for a specific user, no exclusions or context for usage are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide a safety profile (not read-only, idempotent, not destructive), and the description adds valuable detail about exactly what is replaced (the complete configuration) and what is preserved (questions, question groups, and selection/filtering/export settings). This clarifies the overwrite behavior beyond the annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient and front-loaded with the core action. Minor redundancy: the phrase 'the other Quiz set' is slightly awkward but clear. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the two parameters are fully documented, the description adequately covers the copy semantics, exclusions (questions and groups), and preserved properties. It could mention error conditions or merge behavior, but the 'replace' semantics are clearly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the two parameters with descriptions, so the baseline applies. The description adds minimal semantic value, only clarifying the direction of copying (target gets source's config), which the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Replace') and a specific resource (Quiz set configuration), and explains that only configuration is copied while questions and question groups are not. This differentiates it from copying an entire quiz, though it does not explicitly name a sibling tool such as edubase_patch_quiz_settings for a partial update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need another quiz's configuration but want to keep the target's questions, selection, filtering, and export settings. However, it does not explicitly state when NOT to use it or mention alternatives like edubase_post_quiz_settings or edubase_patch_quiz_settings. Usage guidance is present but implicit.
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 readOnlyHint=false, so the description's emphasis on 'Permanently' adds minimal value. The description repeats the destructive nature without providing additional behavioral details like cascading effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It efficiently conveys the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description is sufficient. However, it could be improved by mentioning that deletion is irreversible or that the question must belong to a quiz, but lacks such context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description ('external unique question identifier'). The tool description does not add any further meaning or usage hints beyond what the schema provides, resulting in no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a Quiz question', which is a specific verb-resource pair. Among many sibling delete tools, this explicitly targets quiz questions, distinguishing it from other delete tools like 'edubase_delete_quiz' or 'edubase_delete_exam'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as when to use 'edubase_delete_quiz_questions' for bulk deletion. The tool name and context imply its usage for deleting a single question, but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral hints: destructiveHint=true (deletion), idempotentHint=true (safe to retry), and readOnlyHint=false (mutating). The description corroborates the destructive nature by stating 'Remove', adding no contradiction. Together, they offer strong transparency. The description does not add new behavioral details beyond annotations, but the annotations already carry the load well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the purpose with no extraneous words. It is perfectly sized for its function and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, both required, no enums, no nested objects), the description plus annotations and output schema provide sufficient completeness. The presence of an output schema means return values need not be described. However, missing details like prerequisites (e.g., does the tag need to exist?) slightly lower the score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters 'quiz' and 'tag' are defined in the schema with basic descriptions. The description adds no additional meaning (e.g., format, constraints, or how tag is identified), thus does not enhance beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Remove) and the resource (tag attachment from a Quiz). It distinguishes the tool from siblings like edubase_post_quiz_tag (add tag) and edubase_delete_quiz (delete whole quiz), though it does not explicitly differentiate from other tag deletion tools like edubase_delete_course_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The minimal description implies use when a tag needs to be removed from a quiz, but provides no guidance on when not to use it (e.g., if the tag is shared or required), nor does it suggest alternatives like edubase_post_quiz_tag for adding or edubase_delete_quiz for deletion of the entire quiz.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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=true, so the agent knows this is a safe, read-only, idempotent check that may return 'unknown' results. The description adds the direct behavioral meaning ('check if attached'), which aligns well with and adds minimal value beyond annotations. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. Every word earns its place. There is no unnecessary elaboration or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, boolean output likely, rich annotations), the description is mostly adequate. It does not explicitly state the return type (e.g., boolean or existence flag), but the presence of an output schema (not provided in input) likely fills that gap. The openWorldHint suggests it may return 'unknown' status, which the description doesn't mention but the annotation covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('tag' and 'class' identification strings). The description does not add any additional meaning about parameter types, formats, constraints, or relationships beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if tag is attached to a class' clearly states the verb ('check'), the resource ('tag'), and the target context ('class'). It distinguishes itself from sibling tools like 'get_class_tags' (which lists tags) or 'post_class_tag' (which attaches). While clear on the check, it does not explicitly say it returns a boolean or existence status, which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification (checking existence of a tag-class association). However, it does not explicitly state when to use this over alternatives like 'get_class_tags' (for listing all tags on a class) or 'get_tag' (to get tag details). No when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about the field types but doesn't disclose additional behavioral aspects like response structure or permissions, which is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the core action and resource, the second clarifies what 'fields' means. No redundancy and all information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, an output schema exists, annotations cover safety, and the parameter is fully documented. The description explains what is returned conceptually. Only a direct usage guideline is missing, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'exam' parameter with 'exam identification string'. The description adds no further detail about the parameter, so it doesn't go beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'user data fields of an exam'. It further elaborates what these fields are (built-in name, email, phone, and custom fields), distinguishing it from mutation tools like post/delete_exam_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the read-only nature and the context of fields are evident, the description does not explicitly state when to use this instead of sibling tools (e.g., edubase_post_exam_fields or edubase_get_exam_settings). The intended use is implied but not stated directly.
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, idempotentHint, and non-destructive behavior, so the description's job is lighter. It adds useful context by stating that the returned status specifically conveys whether new tests can be started, which helps agents interpret the result. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly introduces the tool and its purpose. Every word contributes meaning; no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 required parameter, a full set of annotations, and an output schema, the description is complete enough. It might have added a note that the exam must already exist or how status values map to test-starting permission, but these details are likely captured in the output schema or the openWorldHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description, so the baseline is 3. The description itself does not elaborate on the required 'exam' parameter, but the schema describes it as an exam identification string, which is sufficient for a single straightforward parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: getting the status of an exam, and clarifies the semantics by noting the status indicates whether new tests can be started. This distinguishes it from sibling tools like the one that sets exam status (edubase_post_exam_status) and from generic exam retrieval 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives. The description and readOnly hint imply a read operation, but there is no explicit mention of the alternative setter tool (edubase_post_exam_status) or any condition that would favor a different getter.
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, openWorldHint=true, which cover safety and idempotency. The description adds no further behavioral details (e.g., pagination, response format). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter and an output schema present, the description is mostly sufficient. It lacks details about output content (e.g., fields returned), but the output schema likely covers that. However, no mention of potential empty results or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'exam' is fully described in the schema as 'exam identification string'. The description adds no additional meaning beyond that. Schema coverage is 100%, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all users on an exam' uses a specific verb ('List') and clearly identifies the resource ('users on an exam'). It effectively differentiates from siblings like 'edubase_get_exam' or 'edubase_get_exam_branding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (listing exam users) but provides no explicit guidance on when to use this tool versus alternatives like 'edubase_post_exam_users' or 'edubase_delete_exam_users'. No when-not-to-use indications.
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, idempotentHint, destructiveHint=false, and openWorldHint. The description adds no behavioral details beyond stating the check operation, such as what happens on success/failure or the return format. With annotations covering safety, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loading the core purpose with zero redundancy. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only check with a complete input schema and an output schema (present but not shown), the description is sufficient. It could be improved by explicitly stating the return type (e.g., boolean) but remains complete given existing structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (integration, tag) have descriptions in the schema. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly defines the resource as 'tag attached to an integration'. This distinguishes it from sibling tools like get_integration_tags (which lists all tags) and other tag-check tools, as it specifies a membership check on a single integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verifying tag attachment, but it does not explicitly mention when to use it versus alternatives like post_integration_tag (attach) or get_integration_tags (list). No exclusion criteria or context signals are provided beyond sibling names, leaving the agent to infer usage.
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 'Check if tag is attached' is consistent but adds no additional behavioral context (e.g., what happens if tag not found, authentication requirements, rate limits). The description is not contradictory to 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It directly states the core function without elaboration, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover read-only/idempotent behavior, the description is complete enough for a straightforward existence check. It could briefly mention that the result is boolean or indicate the return format, but the presence of the output schema alleviates that need. Minor gap in not clarifying response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema ('tag identification string', 'organization identification string') with 100% coverage. The description adds no further semantic detail about format, validation rules, or usage beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and resource 'tag attached to an organization', clearly indicating a boolean existence check. It distinguishes from sibling tools like edubase_get_organization_tags (list all tags) and edubase_get_tag (get tag details) by implying singular verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the naming pattern (singular vs plural) implicitly suggests usage for existence checking, there is no direct mention of context or exclusion criteria. The guidance is only implied, 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, aligning with the 'Get' action. The description adds that thresholds and grades are included, which is content rather than behavior. It does not disclose additional behavioral context such as error conditions or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the action and key result detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the annotated schema (read-only, idempotent, single fully-described parameter) and the available output schema, the description provides sufficient information for correct invocation. It does not explicitly mention when to choose the list variant, but that gap is minor for a single-resource getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the sole parameter 'preset' as an identification string. The description does not elaborate on how to format or interpret this parameter, so it adds no extra semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get), a clear resource (grading preset), and highlights that it returns thresholds and grades. This clearly differentiates it from the plural 'get_quiz_grading_presets' list operation and other preset mutation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular 'a grading preset' implies retrieving one preset by identifier, but the description offers no explicit guidance on when to use this versus alternatives like get_quiz_grading_presets or the post/patch/delete operations. No exclusions or selection criteria are provided.
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, destructiveHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the hierarchy context but does not reveal additional behavioral traits such as pagination, permissions, or output format. With annotations handling the core safety traits, the description is adequate but not above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and adding only necessary context about hierarchy. No redundant or vague wording, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one required parameter and existing output schema, the description provides enough context about the resource structure. It could optionally mention pagination or ordering, but this is not essential for a basic list operation. The hierarchy explanation adds value beyond minimal completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'quiz' has a schema description ('Quiz identification string') covering 100% of parameters. The tool description does not add further meaning or constraints beyond the schema, so it remains at baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description declares the tool lists all questions and question groups in a quiz set, clarifying the hierarchy between questions, quiz sets, and exams. This clearly specifies the verb (list), resource (questions and question groups), and scope (in a quiz set), distinguishing it from sibling tools like edubase_get_question 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/5Does 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_get_questions. While the hierarchical context is helpful, there are no direct statements about when to choose this tool or exclude others.
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 provide readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the 'owned and managed' scope, which is useful context about permissions but does not disclose pagination, maximum results, or filtering behavior beyond what parameters imply. With strong annotation coverage, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It effectively communicates the core purpose without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only optional parameters fully described in the schema, and has an output schema (not shown here but mentioned as present). The description covers the essential purpose and scope. Minor gap: it doesn't mention pagination behavior explicitly, but the schema covers defaults, so the overall package is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: page, limit, and search each have descriptions. The tool description does not add extra meaning beyond what the schema already provides, so the baseline score of 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'tags', with a specific scope 'owned and managed'. It distinguishes from sibling tools like edubase_get_tag (singular) and resource-specific tag listers (e.g., edubase_get_exam_tags) by implying a general tag listing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear action but does not explicitly state when to use this tool versus alternatives like edubase_get_tag or resource-specific tag endpoints. The scope 'owned and managed' hints at context, but there is no explicit when/when-not guidance, leaving the agent to infer based on naming conventions.
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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds no new behavioral information beyond these annotations, which is acceptable but not improved upon.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of minimal length. Every word serves a purpose, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no parameters, and presence of an output schema, the description is sufficient. However, adding a note about the return value (e.g., 'returns the current user object') would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. For zero-parameter tools, the baseline score is 4, as the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check current user' clearly states the action (get/check) and resource (current user). It distinguishes from sibling tools like 'edubase_get_user' which implies retrieving a specific user 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. While 'current user' implies the authenticated user, it lacks explicit context or exclusions, leaving the agent to infer usage.
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 declare readOnlyHint, idempotentHint true and destructiveHint false, so the safety profile is fully covered. The description adds no further behavioral context beyond the membership scope—no pagination, no handling of missing users, no permission requirements—but it does not contradict the annotations. Given the annotation coverage, a mid score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence delivers the whole semantic payload with no filler, and the most important words ('List', 'organizations', 'user', 'member') come first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity and has an output schema, so the description does not need to describe return values. Together with a one-parameter schema, the definition is mostly sufficient to call the tool given a known user identifier. It is only lacking a small amount of situational guidance about user-identification formats or alternatives, which is captured in the other dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for `user` as a 'user identification string', and the description clarifies that this parameter is the user whose memberships are listed. No format, whether it must be an internal ID or email, or whether it can represent the current user, is specified, so the description adds only minimal meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a single clause with a specific verb ('List'), a resource ('organizations'), and a scoping qualifier ('a user is member of') that clearly distinguishes membership lookup from system-wide organization listing or group/class lookups. This is sufficient to pick it over siblings like edubase_get_organizations or edubase_get_organization_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state any explicit condition for use, nor does it name alternatives or exclusions (e.g., 'for the current user use get_user_me' or 'for all organizations use get_organizations'). The intended use is only implicit in the tool's operation, so an agent gets no explicit help choosing among related organization/user endpoints.
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 are provided: readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds the key behavioral trait that it updates memberships if the user is already a member. This adds value beyond annotations. However, it doesn't disclose other behaviors like whether the notify parameter triggers an email, or what happens on failure. A 3 is appropriate as it adds some but not exhaustive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. Every word adds value: the first sentence states the action, the second clarifies idempotency on re-assignment. This is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 params (all described in schema), no output schema, and moderate complexity (batch operation on users and classes). The description covers the core behavior and an important edge case (updating existing memberships). It omits what the response contains (e.g., success/failure per user-class pair) but with no output schema, that's acceptable. A 4 is appropriate for being mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description doesn't add any parameter-specific meaning beyond what's in the schema. It could have clarified the format for user/class IDs (e.g., are these UUIDs or names) or provided examples for the expires parameter. No added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Assign' and resources 'user(s) to class(es)'. It distinguishes from siblings like edubase_get_class_members (read) and edubase_delete_class_members (delete), and other membership tools. However, it could more explicitly contrast with edubase_post_class_members if that exists, but among siblings it's clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for assigning or updating memberships. It says 'Updates memberships if already member of a class', which gives guidance on idempotent-like behavior. While it doesn't explicitly state when not to use it or name alternatives, the update clause helps agents decide. Could be improved by stating when to use delete_class_members instead.
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 cover the read/write/destructive profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds contextual traits like 'time-constrained' and 'secured', but does not disclose additional behavioral details such as side effects, permission requirements, or post-creation processes. It neither contradicts annotations nor richly expands beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. The core action is front-loaded, and the critical constraint (must come from existing Quiz set) is explicitly highlighted in the second sentence. Very efficient for the amount of context provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient given the rich schema (all params documented) and presence of an output schema. It clearly explains the prerequisite and the nature of exams. Minor gap: it does not clarify the relationship to sibling settings operations, but that is not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are already documented in the input schema with descriptions (100% coverage). The tool description adds no new parameter-specific meaning beyond restating the 'quiz' prerequisite. Baseline 3 is appropriate because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create), the resource (a new exam), and the key constraint (from an existing Quiz set). It also distinguishes this tool from sibling exam-related operations by emphasizing the top-level hierarchy and that exams are instances of Quiz sets, which is unique to the creation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case—creating an exam—and states a prerequisite (must use an existing Quiz set). However, it does not explicitly say when to use this tool versus related operations like patch_exam or post_exam_settings, nor does it mention alternatives 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 already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a mutating, non-destructive, non-idempotent operation. The description adds the conceptual context of Quiz sets feeding into Exams but does not disclose additional behavioral details like permissions or side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core action and then adds a brief, relevant explanation of the resource type. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a rich input schema (9 params), full schema coverage, and an output schema, the description adds the key context of how Quiz sets relate to Exams. It does not need to explain return values since an output schema exists. A minor gap is the lack of guidance on when to use different modes/types, but those are covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 100%, all parameters are already documented in the schema. The description adds no extra parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Quiz set') and defines what a Quiz set is, differentiating it from other entities like Exams by noting it can 'power multiple Exams'. This provides a specific verb and resource with useful 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning Quiz sets are 'used for practice or to power multiple Exams', giving some context for when to create one. However, it does not explicitly state when not to use this tool or mention alternatives, leaving the routing to inference.
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 provide basic safety traits (readOnlyHint=false, destructiveHint=false). The description adds that questions can exist independently from quiz sets, which is useful behavioral context. However, it does not explain what happens if the quiz/group doesn't exist or if questions are already assigned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the primary action, and the second adds important context about independence. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the simplicity of the tool (assign questions), the description covers the core use case adequately. It could mention error states or prerequisites, but the information provided is sufficient for an AI agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters (100%) with descriptions. The description adds minimal extra meaning beyond the schema—only the implicit context that 'group' is a question group title, which is already in the schema. No elaboration on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'assign' and the resource 'question(s) to a Quiz set, or one of its question group,' distinguishing it from sibling tools like edubase_delete_quiz_questions (remove) and edubase_post_question (create new). The second sentence adds context about questions existing independently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when assigning existing questions to a quiz or group, but does not explicitly state when to use this tool versus alternatives like edubase_post_question for creating new questions or edubase_delete_quiz_questions for removing. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, open-world, and non-destructive behavior, so the description's main addition is the 'check' nuance—suggesting the tool can verify existence or status. It does not contradict the annotations. This adds modest context beyond the structured hints, justifying a slightly above-baseline score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short words ('Get/check integration') with no filler. It is front-loaded and efficient. Every element conveys purpose, and it is appropriately sized for a simple single-parameter read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only resource fetch with a single well-covered parameter and an output schema present, the description is nearly complete. The only missing context is clarification of what 'check' means behaviorally (e.g., existence vs. full retrieval) and the relationship to the plural sibling edubase_get_integrations. Those gaps are minor given the rich annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the only parameter (integration) at 100%, so the baseline is 3. The description's 'integration' resource reference reinforces that the parameter identifies the integration to retrieve. It does not conflict with or add much beyond the schema, but with full schema coverage and a clear resource tie, 4 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get/check integration' names a verb ('Get/check') and a resource ('integration'), which is sufficient to convey the tool's purpose. It is reasonably distinguishable from siblings like edubase_get_integrations (plural list), though it could more explicitly clarify that it retrieves a single integration by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read/check operation but provides no explicit guidance on when to choose this tool over edubase_get_integrations or edubase_get_integration_keys. The annotations (readOnlyHint, idempotentHint) give some context, but the description itself does not state conditions or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral details such as pagination, ordering, or empty-result behavior. It is consistent with annotations but offers no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the operation without any redundant phrasing. It is appropriately front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one well-documented parameter, existing annotations covering safety, and an output schema present, the description provides sufficient information for an agent to select and invoke the tool correctly. No critical gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'video' parameter documented as 'video identification string'. The tool description does not supplement this with additional parameter context, so it relies on the schema, which is adequate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'all attached tags of a video', making the tool's purpose unmistakable. It also implicitly distinguishes from the singular sibling 'edubase_get_video_tag' by specifying 'all' and plural 'tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. However, the phrase 'all attached tags' implies it is the intended tool for retrieving the complete tag set for a video, and the naming pattern across siblings makes the context reasonable to infer.
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 include readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description correctly identifies it as a create operation, consistent with annotations. However, it does not elaborate on behavioral details beyond what annotations provide—such as whether the creation requires specific authorization (e.g., only admins or certain role), whether existing permissions for the same user/class are overridden or fail, or what the response format looks like. The output schema exists but the description does not leverage it to hint at return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that accurately captures the tool's purpose. No fluff or unnecessary detail. Every word is meaningful, and it is easy to parse quickly. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 input schema, the description provides adequate purpose and basic context. However, it lacks information about behavioral nuances such as idempotency (the hint is false) and potential side effects. For a permission-creating tool, agents might benefit from knowing whether duplicates are allowed or whether the operation is scoped to a specific role within the class.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (user, class, permission) with clear descriptions and an enum for permission values. The schema description coverage is 100%, so the description does not need to repeat this information. However, it could add value by explaining how the parameters interact—for example, whether the user must already be a class member, or what happens if the permission already exists. Still, the baseline is high due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create new permission for a user on a class', which is a specific verb+resource combination. It clearly differentiates from sibling tools like edubase_delete_class_permission or edubase_get_class_permission, making the tool's distinct purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when adding a new permission to a class for a user, but it does not explicitly state when not to use this tool or mention alternatives like edubase_patch_user or other permission-related tools. There is no guidance on prerequisites (e.g., does the user need to be a member of the class first?) or scenarios where updating an existing permission might be more appropriate.
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-readOnly (write operation), non-destructive, idempotent false, openWorldHint true. The description adds behavioral context: it updates memberships if already a member (idempotency clarification) and assigns users. It does not contradict annotations. No details on side effects or auth requirements, but annotations cover safety profile well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the primary action, the second clarifies idempotent-like behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description doesn't explain return values, which is acceptable. Given 7 parameters (all described in schema), 3 enums, and complex permission fields, the description is complete enough for an agent to understand the core action. It could mention that permissions are optional and default values apply, but the schema already covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by summarizing that the tool assigns/updates memberships, which contextualizes the parameters. It does not add detailed semantics for each param beyond the schema, but given full coverage, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Assign') and resource ('user(s) to an organization') and distinguishes itself from siblings like edubase_post_organizations_members by noting it updates memberships if already a member. However, the title is missing and the description could more explicitly contrast with other member-management 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (assigning or updating memberships) but does not provide explicit guidance on when not to use this tool or mention alternatives among siblings (e.g., edubase_post_organizations_members, edubase_delete_organization_members). No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false) and don't conflict. The description adds the trigger_event constraint but does not explain what happens when triggered (e.g., HTTP request sent, side effects, success/failure behavior). Given the sparse annotations, it would benefit from more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, and a concise condition. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 params and no output schema, the description covers purpose and key constraint. However, it lacks details like what the trigger does (e.g., sends HTTP request), required permissions, or error handling. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear descriptions. The description adds only 'with optional custom payload', which matches the data parameter. No additional meaning beyond schema is provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger'), the resource ('organizational webhook call'), and includes a crucial constraint ('Only triggers webhooks with trigger_event set to api!'). It effectively distinguishes from sibling tools like delete or patch webhook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a key usage condition ('Only triggers webhooks with trigger_event set to api!'), which helps the agent decide when to use this tool. However, it does not provide explicit alternatives or when-not-to-use scenarios, but the condition itself is clear.
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 indicate destructive behavior (destructiveHint: true), and the description adds valuable specifics: 'The PIN code and the shortlink of the exam are removed as well.' This discloses concrete side effects beyond the generic annotation, giving the agent a clearer picture of the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the core action, the second adds the critical side effect. There is no redundant or extraneous information, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the combination of description, annotations, and parameter schema covers the essential operational aspects. The description adequately explains the primary effect and key side effects, though it does not mention how to re-enable automatic login or any permission prerequisites, which are minor omissions given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'exam' is fully described in the schema as 'exam identification string', so schema description coverage is 100%. The tool description does not add any additional parameter semantics, which aligns with the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Disable automatic login for an exam' and specifies the side effect of removing the PIN code and shortlink. This distinguishes it from siblings like edubase_post_exam_autologin and edubase_get_exam_autologin, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives, such as edubase_post_exam_autologin for enabling login. However, the tool's specific name and action make its use case reasonably implicit, providing minimal guidance beyond the operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false, so the safety profile is fully covered. The description adds no behavioral context beyond listing tags, which is acceptable for such a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no redundant wording. It front-loads the core action (list) and the scope (attached tags of a course).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with full annotations, an output schema, and one documented parameter, the description is sufficient. It lacks only minor details like return format, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'course' is described as 'course identification string'. The description adds no further meaning about the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all attached tags of a course' uses a specific verb and resource, clearly distinguishing this plural listing tool from its singular sibling get_course_tag. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it lists tags attached to a specific course, which implies when to use it versus alternatives like get_course_tag (singular) or get_tags (global listing). However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a read-only, idempotent, safe operation, so the bar for additional behavioral disclosure is lower. The description adds useful context about the return scope ('both global and owned, custom presets'), which clarifies what exactly will be listed. No mention of pagination or limits, but for a simple list operation with an output schema, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main purpose is front-loaded in the first sentence, and the second sentence clarifies the exact scope of results. Every word contributes information; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, required as none, output schema present, read-only annotations), the description covers the essential usage and return scope. It could be slightly more explicit about the difference with the singular preset endpoint, but the inferred list behavior plus schema makes it reasonably complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (language) is 100% covered by the schema description, which already explains the filter behavior and that presets not bound to a language are included. The tool description adds no additional parameter detail, so the baseline of 3 for full schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('List'), resource ('grading presets'), and scope ('available for the user'). It explicitly mentions both global and owned custom presets, which distinguishes it from the singular sibling 'edubase_get_quiz_grading_preset' — the plural vs singular distinction is clear even without an explicit reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (listing grading presets for a user) but does not explicitly say when to use it versus the singular getter or any other sibling tool. No exclusions or alternative routing advice is provided, but the core context is inferable from the plural naming and available-for-user phrasing.
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 discloses a non-obvious side effect: view_results_identifier is cleared when the selected custom field is no longer a unique free text field. It also explicitly states that the custom field list is replaced, which is important mutation behavior. Annotations already indicate a non-idempotent write, and the description adds context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences: the first defines the operation, the second warns about a conditional side effect. There is no redundant or filler text, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation with a complex nested array, the schema provides thorough parameter documentation, and an output schema exists. The description supplies the essential orientation and the key side effect. It could add an explicit caution that replacement is permanent, but 'replace the complete list' and the schema note adequately cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema provides very detailed descriptions for exam, name, email, phone, and fields. The tool description adds no additional parameter-specific semantics beyond referring to built-in fields. The baseline of 3 is appropriate when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states specific verbs ('change' for built-in fields, 'replace' for custom fields) and clearly names the resource (exam) and scope (complete list). This distinguishes it from sibling tools like edubase_get_exam_fields (read) and edubase_delete_exam_fields (delete all). The purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the write/update operation for exam fields, but it does not explicitly name when to use this tool versus alternatives. The schema's fields parameter mentions edubase_delete_exam_fields, but the primary description lacks that routing guidance. Usage context is implied rather than explicit.
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 show destructiveHint=false, so the tool is non-destructive. The description adds transparency about caching: a previous valid link is returned instead of generating a new one. This behavioral insight is useful beyond what annotations provide, though it doesn't detail other aspects like authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action ('Generate download link') and then providing the caching detail. No redundant or filler content. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema (not shown but present). The description covers the core behavior and caching. It could mention what happens if the question does not exist or what the output contains, but the output schema likely covers that. Missing explicit error conditions, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the 'id' parameter described as 'external unique question identifier'. The description adds no additional semantics beyond the schema. Since coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a download link for exporting a question in JSON format. It also notes caching behavior (returns existing link if valid). This distinguishes it from siblings like edubase_get_question which retrieves data directly, and edubase_post_question which creates new 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (exporting JSON) but does not explicitly state when not to use or mention alternatives. For example, if the agent wants the raw question data, edubase_get_question might be more appropriate. The caching detail provides some guidance but not enough for optimal tool selection.
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 aligns with annotations: destructiveHint=true (removing a tag is destructive) and idempotentHint=true (removing an already removed tag likely does nothing). The openWorldHint=true may be questionable since the tool requires both exam and tag IDs, but it does not contradict. The description adds value by explicitly stating 'tag attachment' (implying it only removes the association, not the tag itself), which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that clearly states the operation. No wasted words – every word earns its place. Front-loaded with the action, it communicates effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required params, no enums, output schema present) and the availability of sibling tools like edubase_delete_exam_tag (contrast with edubase_post_exam_tag), the description is complete enough for a simple associative removal. However, it lacks context about side effects (e.g., does this affect the exam's behavior or other tags?) and return values. With an output schema present, return values are clarified by schema, but behavior details could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining that the tool removes a 'tag attachment' (not the tag itself), which clarifies semantics for the two required parameters (exam and tag). However, it does not elaborate on format, source, or validation rules for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a tag attachment from an exam' uses specific verbs ('Remove') and resources ('tag attachment', 'exam') to clearly define the tool's action. It distinguishes this tool from 'edubase_post_exam_tag' (which would add a tag) and other delete tools like 'edubase_delete_exam', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when or when not to use this tool. It does not mention alternatives like 'edubase_tag' operations for removing tags from other entities, but the implicit context suggests it is for exam tags only. No explicit guidance on prerequisites (e.g., tag must already exist) or disclaimers about side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint, covering safety and idempotency. The description adds the nuance of returning 'the latest' certificate, which is beyond annotations. No contradictions. A minor gap: no mention of what happens if no certificate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 9-word sentence that efficiently conveys the tool's purpose and scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (mentioned in context), the description does not need to elaborate on return values. The tool is simple with two required params, and the description sufficiently covers the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for 'exam' and 'user' are present (100% coverage), so baseline is 3. The description does not add further semantic detail beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'certificate details', specifying it is for a specific exam and user, and notes it returns the latest certificate. This distinguishes it from sibling tools like edubase_post_exam_certificates_user_download, which is a download 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the latest certificate details, but does not explicitly state when to use or not use this tool, nor contrast it with alternatives like the download tool. The context is clear but lacks explicit 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 already cover readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds valuable context about survey behavior—that grading and results-viewing settings are not returned for surveys, and export columns are not configurable—which enriches the agent's understanding beyond structured metadata. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The core purpose is front-loaded, and the additional detail about surveys is relevant and succinct. No irrelevant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET with one parameter and read-only annotations, the description is complete. It covers the main use case and flags the special case of surveys with enough detail for an agent to call the tool correctly and understand the output expectations. The output schema further eliminates the need to describe return structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'exam' parameter with a description ('exam identification string'), at 100% coverage. The description does not add further detail about parameter format or usage, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Get' with resource 'settings of an exam' states exactly what the tool does. It also clarifies that for surveys, grading and results-viewing settings are omitted, and export columns are not configurable, which further defines the scope of the returned data. This clearly distinguishes it from sibling tools like POST/PUT/PATCH exam settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving exam settings based on the GET verb, but it does not explicitly state when to use it versus the sibling tools for creating or updating settings. The survey-specific details provide some context about which settings are relevant, but no exclusions or alternative recommendations 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, idempotentHint, and destructiveHint=false; the description adds no additional behavioral caveats beyond 'all attached tags'. It does not contradict the annotations, but provides little incremental disclosure about return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence front-loads the verb and object with no filler or redundancy. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only list operation with annotations and an output schema, the description is sufficiently complete. An agent can determine what to pass and what the call will do without requiring further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single required parameter 'exam' is documented as 'exam identification string'. The description adds no further meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a concrete resource ('all attached tags of an exam'), clearly identifying the operation and distinguishing it from singular get/post/delete exam_tag siblings. The tool name and description align on 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It is clear this tool is for retrieving an exam's tag list, and naming the resource 'exam' distinguishes it from other get_*_tags tools. It does not explicitly list alternatives or when-not-to-use conditions, so it stops short of a 5.
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 discloses a key behavioral trait: it only copies settings that are not yet configured, meaning it avoids overwriting existing configurations. This goes beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and clarifies the tool's non-destructive, selective nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that captures the tool's core behavior without any fluff. It is front-loaded with the action and immediately states the key constraint, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, annotations (including idempotent and non-destructive hints), and presence of an output schema, the description is sufficient. It explains the exact operation and scope, and no additional context appears necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter descriptions, so the schema already covers parameter meaning. The description only adds the overall operation and does not elaborate on specific parameters beyond what the schema provides, which meets the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the precise verb 'Copy' and names the resource 'settings from another exam', specifying the exact scope: only those not yet configured in the target exam. This clearly distinguishes it from other exam settings tools like edubase_post_exam_settings or edubase_put_exam_settings, which imply full writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when the target exam has some settings unconfigured and you want to inherit them from a source exam. However, it does not explicitly state when NOT to use this tool or mention alternatives (e.g., using put_exam_settings for full overwrite), leaving some inference to the agent.
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 discloses the side effects: closing running tests, detaching results, resetting accounts, and the specific constraints via referenced settings. This adds value beyond the annotations, which only say readOnlyHint=false. However, there is a potential contradiction with destructiveHint=false considering the resetting of accounts; thus the transparency is good but the contradiction lowers it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: the main action is stated first, followed by side effects, and ends with conditions. It is not overly verbose and each sentence contributes to understanding, though it could be slightly more succinct by separating the constraints into a cleaner list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema covers all parameters, the description sufficiently covers the tool's behavior and preconditions. It explains the purpose, side effects, and limitations, making it complete for a mutation tool. Slight gap: it doesn't mention potential errors or edge cases beyond restrictions, but the referenced settings handle those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no additional parameter-specific details beyond what the input schema already covers at 100% coverage. The schema fully explains exam, force, and notify, so the description merely restates the overall purpose without enriching parameters. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a new exam round and describes the specific effects (closing tests, detaching results, resetting accounts). It is unambiguous and distinguishable from siblings, as no other listed tool performs this round-starting operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists conditions under which a new round cannot be started (locked, archived, frozen, results viewing period started), giving clear guidance on when not to use. However, it does not mention alternative tools or when to prefer this over others, but since no direct alternative exists, the exclusion is sufficient.
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 non-readonly, non-destructive behavior, but the description adds valuable context by explaining that patterns are stored with the exam and reused as defaults for future calls. It also discloses the interaction between count and names (count ignored when names is provided). However, it does not detail side effects like whether existing accounts are overwritten or what happens on partial success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it leads with the core purpose, then explains placeholders, and ends with persistence semantics. Sentences are information-rich with no filler, though it could be slightly trimmed. The structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with eight parameters and complex rules, the description covers pattern syntax, parameter precedence, and defaults. Given that an output schema exists (though not shown), the lack of return-value details is acceptable. What is missing is explicit guidance on required permissions or error handling, but overall it is comprehensive enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, but the description adds critical semantic relationships: placeholders usable in patterns, the defaulting behavior for name/password/username, and the constraint that emails must match names in count. These details are not fully captured in the schema and materially improve correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Generate') with a clear resource ('exam accounts') and the assignment target ('assign them to an exam'). It distinguishes the tool's batch-generation intent from simpler account creation tools by detailing placeholder-based pattern generation, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (bulk account generation for an exam) but does not explicitly mention alternatives or when NOT to use it. It provides clear functional context, yet lacks direct exclusionary guidance. The behavior of pattern defaults and ignored parameters helps infer usage, but it is not as explicit as it could be.
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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by clarifying the exact operation is checking a specific permission for a specific user on a class. It does not contradict annotations and aligns well with the safe, read-only behavior implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose. Every word is necessary, and it is front-loaded with the key action and resource. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which presumably describes the boolean result), the simple description is sufficient. The tool's purpose is straightforward: checking a permission. The context signals (100% schema coverage, annotations) support completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all three parameters (user, class, permission) described. The description adds no additional parameter detail beyond what the schema provides. The enum for permission (view/report/control/modify/grant/admin) is well-defined in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if a user has permission on a class' uses a specific verb ('Check') and clearly identifies the resource ('user') and target ('class'). It directly mirrors the tool name and is distinct from siblings like edubase_post_class_permission (which sets permissions) and edubase_delete_class_permission (which removes them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for checking existing permissions, not setting or deleting them. It differentiates clearly from sibling tools like edubase_post_class_permission and edubase_delete_class_permission by being a 'check' rather than a mutation. However, it does not explicitly state when NOT to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (true), idempotentHint (true), openWorldHint (true), and destructiveHint (false), strongly indicating a safe, read-only, idempotent operation. The description confirms the read-only nature by stating 'Check if a user has permission' and does not contradict annotations. It adds minimal behavioral context beyond that, but the annotations are already very comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly conveys the tool's purpose. It contains zero unnecessary words and is front-loaded with the key action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 params, simple enum, output schema present, no nested objects) and excellent annotations, the description is adequate. It tells the agent what the tool does and its read-only nature. However, it does not explain the output behavior—though since an output schema exists, that is not required. It could briefly mention when this check succeeds/fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 100% with clear parameter descriptions and enum values for `permission`. The description does not add any additional semantics beyond what the schema provides. Per guidelines, when schema coverage is high (>80%), baseline is 3, and the description meets but does not exceed this baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a user has a specific permission on an organization, using the verb 'Check' with the resource 'organization permission'. This distinguishes it from sibling tools like `edubase_post_organization_permission` and `edubase_delete_organization_permission`, which perform different operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to verify a user's permission level on an organization. It does not explicitly state when not to use it or mention alternatives, but among the many permission-related sibling tools, the 'get' prefix clearly indicates it's for checking, not modifying. Adding context on when to use alternatives like the post/delete permission tools would improve clarity.
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 (readOnlyHint=false, destructiveHint=false) indicate a write operation, and the description adds that it updates memberships if the user is already a member. This provides useful behavioral context beyond annotations, though it does not detail side effects like response 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence states the primary action, and the second adds the update behavior. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters fully documented in schema and no output schema required, the description covers the purpose and key behavior (updating existing memberships). It could add guidance on the format of expires but the schema already describes that. Overall, adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description does not add significant meaning beyond the schema descriptions (class, users, expires, notify). For example, 'expires' description in schema is adequate, and description does not elaborate. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Assign user(s) to a class' and adds the nuance of updating existing memberships, which distinguishes it from sibling tools like edubase_get_class_members (read) and edubase_delete_class_members (remove).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding users to a class, but does not explicitly contrast with alternatives like edubase_post_classes_members (which may batch multiple assignments). However, the core use case is clear, and the update behavior is mentioned.
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 discloses key behavioral traits beyond annotations: it reuses existing valid links. Annotations have readOnlyHint=false and idempotentHint=false, yet the description implies some idempotency by returning existing links. This could be slightly misleading but the description adds value by explaining the caching 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, no wasted words, and the purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple string parameters, an output schema (exists), and annotations, the description covers the main behavior. It lacks details on prerequisites (e.g., certificate existence) or error handling, but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('exam identification string', 'user identification string'), achieving 100% coverage. The description does not add further meaning beyond these.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate download link for the latest user exam certificate.' It specifies the verb (generate) and resource (download link for certificate), and distinguishes from sibling tools like edubase_get_exam_certificates_user which likely retrieves certificate info rather than generating a link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (to get a download link for the user's latest exam certificate) and describes behavior for existing links ('If a previous valid link exists, it will be returned instead'). However, it does not explicitly contrast with alternatives or 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?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds important behavioral context by listing the conditions that prevent deletion (global presets, in-use presets), which governs when the operation will succeed or fail. It also aligns with idempotentHint=true since attempting to delete an already-deleted preset would likely be idempotent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that states the action and immediately provides the key constraints. There is zero wasted text, and the critical limitation is introduced upfront. This is an exemplary concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, no output schema, and annotations covering the safety profile. The description provides the essential operational constraint (what cannot be removed) that an agent must know before calling. Nothing needed for successful invocation is missing; the agent can safely call this without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'preset', described as 'grading preset identification string'. The description does not add further detail about the parameter format or how to obtain it, but the schema already provides sufficient semantic meaning. Baseline of 3 is appropriate since the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Remove a custom grading preset.' It also specifies the scope (custom) and immediately distinguishes itself from other deletion tools like edubase_delete_quiz or edubase_delete_quiz_questions by targeting a unique resource type. The title annotation reinforces the purpose without conflicting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when NOT to use the tool: global presets and presets used by a Quiz set or exam cannot be removed. This gives the agent a clear boundary for usage. It does not explicitly name an alternative or state 'use this when...' but the exclusion criteria effectively guide the agent on valid conditions. No sibling tool directly overlaps in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, etc. The description adds the 'debugging only' constraint, which is useful context beyond annotations, but no further behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with annotations, the description is complete enough. It states what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, which is acceptable per baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the MCP server API URL (only use for debugging)' clearly states a specific verb and resource, and distinguishes its debugging-only purpose from sibling tools like edubase_mcp_server_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly restricts usage to debugging, providing a clear context. It does not name alternatives but effectively implies when not to 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the debugging context, which provides additional behavioral guidance 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information. There is no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description is complete. It clearly states the purpose and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description does not need to add parameter information, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Get' and the resource 'MCP server version', making the purpose clear. It distinguishes itself from sibling tools, which focus on domain entities like classes, exams, or users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'only use for debugging', providing explicit context for when to use this tool. While it does not list alternatives, no alternative is needed given the tool's simplicity.
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 indicate idempotent and non-destructive behavior, but the description adds a key behavioral detail: it only copies settings that are not already configured, so it never overwrites existing values. This goes beyond the structured annotations and helps the agent predict the operation's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that conveys the operation, its selective nature, and the relationship between source and target without any redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a high-coverage schema and an output schema, the description fully specifies the action and its constraints. No additional context is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions. The description reinforces the target/source relationship but adds no new information beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (copy), a resource (settings), and the exact behavior (only those not configured yet in the target). It distinguishes itself from sibling settings tools by emphasizing selective merging rather than full overwrite or simple retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you want to fill unconfigured settings in a target quiz from a source quiz. It implicitly excludes cases where overwriting is desired, though it does not explicitly name alternatives for that purpose.
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, idempotentHint, and openWorldHint. The description adds behavioral context by stating it returns raw answers, warns about additional permissions, and notes it is not user-facing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three succinct sentences. It front-loads the purpose, then provides a usage guideline and key behavioral detail. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only operation with one parameter and an existing output schema, the description covers purpose, usage, return content, and permission context. It lacks details on result size or pagination, but is sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'exam' parameter ('exam identification string'). The description does not add further semantic meaning beyond that, but schema coverage is high, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get raw results for a specific exam.' It specifies the verb 'get' and the resource 'raw results', and distinguishes from sibling tools like 'edubase_get_exam_results_user' by emphasizing that this returns detailed raw data including all answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Only use this if very detailed results are needed!' and 'It is not meant to be displayed to the user.' This directly informs the agent when to use this tool versus a simpler alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with destructiveHint=true in the annotations, the description adds substantial nuance: archiving makes the result disappear from lists/reports but keeps it restorable by adding the user back; forgetting detaches the play from the user but keeps it for statistics. It also discloses admin-only requirement for non-exam results. This goes well beyond a raw destructive flag and gives an accurate mental model of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each essential: main purpose, the two behavioral branches, the archive-enabling prerequisite, the current-result restriction, and the admin-only restriction. The prose is dense but well-structured, with no fluff or redundant restatement of the title/name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully equips an agent to invoke the tool correctly: it explains what happens in both exam and non-exam scenarios, names the prerequisite setting and its source, notes the current-result limitation, and states permission requirements. Given no output schema exists, the state-change explanation is sufficient; there are no obvious missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of the parameter with 'play' described as 'Quiz play identification string.' The description does not enrich the parameter's meaning (e.g., how to obtain the play ID or expected format), so the schema does the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Archive or forget the result of a Quiz play,' providing a clear verb (archive/forget) and specific resource (a Quiz play's result). It then explains two distinct outcome modes (exam result vs. outside exam), making it unambiguous what the tool does and distinguishing it from generic delete_quiz or delete_exam tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage constraints: exam results can only be archived when the archive setting is enabled (referencing edubase_post_exam_settings), only the current result can be archived, and non-exam results can only be forgotten by administrators. These communicate when the tool is applicable. However, it does not explicitly point to an alternative tool for a comparable action, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond annotations: the link is unauthenticated, single-use, expires in one hour, exports only visible examinees, honors exam export settings, and requires reporting permission. This goes well beyond the basic read/write hints and helps the agent anticipate side effects and access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the core purpose and then adding security, permission, and scoping constraints. Every sentence conveys meaningful operational information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with the highly descriptive input schema and the presence of an output schema, the description covers the important operational aspects: link lifetime, authentication, permissions, visibility scope, and relation to export settings. No critical missing context prevents correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter, including nested properties and enums, has a detailed schema description. The main description adds high-level export context but does not need to explain individual parameters. The baseline of 3 applies because the schema already handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Generate a download link for the results of an exam.' It clearly conveys that this is an export operation producing a shareable link, which is distinct from sibling tools that fetch or manipulate exam/result data directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: the link is unauthenticated and shareable, only visible examinees are included, and reporting permission is required. It does not explicitly name alternative sibling tools or state when not to use this export, but the context is clear enough for an agent to decide when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses significant behavioral nuances: the exam itself stays active while only test starts are controlled, and disabling new tests cancels the scheduled automatic disabling. These are non-obvious side effects that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core action, and each sentence provides essential context without redundancy. It is efficiently structured for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter operation with a full input schema and an existing output schema, the description covers all necessary operational context: when the change is allowed, what the change affects, and a notable side effect. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (exam identification string, allow new tests to be started), covering 100% of parameters. The tool description does not add additional parameter-level meaning, but it is not necessary given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Enable or disable starting new tests on an exam', clearly identifying the action and resource. It distinguishes itself from sibling tools like edubase_get_exam_status by stating exactly what it controls (test start permission) rather than status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual conditions for when the operation is valid: while the exam is active and not yet closed, and explicitly notes that it cannot be used in the results viewing period. It does not explicitly name alternative tools or state when not to use it, but the constraints effectively imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing exactly what is and isn't affected: it copies complete configuration but never copies exam-specific state, and it keeps the target's branding and attached materials. This clearly communicates side effects and reassures about non-destructive behavior, complementing the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). No contradictions 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The main action is front-loaded, and the second sentence efficiently enumerates exclusions and preserved items. Every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (full config replacement) and the presence of an output schema, the description covers the behavior thoroughly: what's copied, what's never copied, and what's kept. It could optionally mention the effect of keep_certificate_settings (default false) in the description, but the schema already documents that. Overall, an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds meaning by clarifying that the 'settings' being copied exclude exam-specific data and state, and that branding and learning materials are kept. This helps the agent understand what the 'source' parameter will actually contribute and what 'exam' (target) retains, adding value beyond the field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replace') and resource ('complete configuration of an exam') with a clear source→target relationship. It also explicitly outlines what is not copied and what is kept, which distinguishes it from other settings-related tools like patch (partial changes) and post (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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear the tool is for replacing an exam's entire configuration with another exam's configuration, and even details exclusions (exam-specific data/state) and preserved elements (branding, learning materials). While it doesn't explicitly name alternative tools or say 'use this when...', the specificity gives strong contextual guidance. It would benefit from a direct note that partial updates belong to patch_exam_settings, but this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the annotations already indicating destructive and idempotent behavior, the description adds valuable context beyond them: it states that built-in fields are kept, that examinee-entered values are retained but hidden, and that the view_results_identifier setting is cleared. These are nontrivial side effects that the annotations do not convey. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each delivering a distinct piece of information: primary action, built-in field exceptions with a pointer to the alternative, data retention behavior, and settings clearance. It is front-loaded with the core action and contains zero filler. Ideal length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description completely covers the tool's effects: what is removed, what is kept, what happens to existing values, and what settings are affected. Given only one parameter and no output schema, no additional context is needed for an agent to invoke the tool correctly. The annotations cover the destructive nature, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'exam' parameter, so the schema already fully documents the parameter. The description does not add any extra semantic detail about the parameter itself (e.g., format or constraints). Baseline 3 is appropriate since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove every custom field of an exam.' It clearly states the scope (all custom fields), differentiates from related tools like edubase_post_exam_fields by specifying what is kept vs. what is removed, and notes the side effect on view_results_identifier. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool for a different use case: 'use edubase_post_exam_fields to turn those off' (the built-in fields). This provides clear when-to-use and when-not-to-use guidance, telling the agent that this tool is for removing custom fields while preserving built-in ones, and directing to the sibling for the opposite need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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