Canvas MCP Server

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Most tools clearly target distinct resources and actions, but there is some potential overlap between patch-page-content and update-page-content (targeted vs full replacement) and among get-submission-documents, get-submission-file-info, and download-submission-file. Descriptions generally help distinguish them.
Naming Consistency5/5
All tool names follow a consistent lowercase hyphenated verb-noun pattern (e.g., list-pages, create-module, delete-quiz). This consistency makes it easy to predict tool behavior from the name alone.
Tool Count1/5
With 60 tools, this exceeds the 50+ threshold for extreme mismatch per the calibration guide. Even for a broad LMS like Canvas, the surface is overwhelming and could benefit from splitting into focused servers by domain (e.g., quizzes, assignments, pages).
Completeness3/5
Core teaching workflows are well covered: assignments, quizzes, pages, modules, submissions, and grading. However, there are notable gaps: announcements only support post (no list/delete), eportfolios lack create/update/delete, and there is no discussion management or course settings beyond basic listing.
Average 3.7/5 across 60 of 60 tools scored. Lowest: 2.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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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?
The annotation idempotentHint=true is present, but the description adds no additional behavioral context such as whether existing grades are overwritten, permission requirements, or effects on other systems. The phrase 'write back' implies mutation but doesn't elaborate on idempotent behavior 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the core action and artifacts. It is efficient with no redundancy, though it could be expanded slightly for completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema. The description fails to explain what happens when optional parameters are omitted, the structure of rubric_assessment, or the response format. It covers the general purpose but is insufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 43%, three of seven parameters lack descriptions. The description maps generic categories (score, grade, rubric points, comment) to potential parameters but doesn't clarify which parameter maps to 'grade' vs 'score' (e.g., posted_grade vs score) or explain 'rubric_assessment.' This leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'write back' and a resource 'a student's submission,' listing the types of grading artifacts (score, grade, rubric points, comment). This distinguishes it from siblings like post-submission-comment which handles only comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the description implies it covers multiple grading actions, it doesn't mention exclusions or recommend it over sibling tools for specific scenarios, leaving the agent to infer.
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 only annotation is idempotentHint: true, which is safe. The description adds a list of updatable fields but does not disclose whether updates are partial (only provided fields) or full replacement, how unspecified fields behave, or any side effects/auth requirements. This is a significant gap for an update tool, though no contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, enumerates the key fields, and contains no unnecessary words. It is appropriately sized for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description is incomplete. It lacks critical context such as partial vs. full update semantics, the expected format for unlock_at, the meaning of publish_final_grade, and any return value or errors. The agent would need to infer too much to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 22% schema description coverage, the description compensates by mentioning five of nine parameters in plain language (name, position, prerequisites, sequential progress, published). However, it omits unlock_at and publish_final_grade, and does not clarify types or formats (e.g., prerequisites as array of IDs, sequential progress as boolean). This provides marginal value beyond the schema but remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Update') and resource ('existing module'), and enumerates specific mutable attributes (name, position, prerequisites, sequential progress, published state). This distinguishes it from create/delete siblings by action type, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create-module or update-module-item. There are no prerequisites, exclusions, or context about typical workflows; the description relies solely on the schema for required parameters.
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 obvious update action. The only annotation (idempotentHint) already covers idempotency, but the description does not disclose other traits like partial updates, required permissions, or side effects, providing no additional value over the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, its brevity lacks structure or elaboration, though it is appropriately front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, no output schema, and mutation semantics, the description is far from complete. It does not explain what happens with unspecified fields, return values, or side effects, making it inadequate for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has its own description. The tool description does not add any meaning beyond the schema, leaving the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'quiz' and context 'in a course', clearly identifying the tool's purpose. It distinguishes from siblings like create-quiz and delete-quiz, though it does not explicitly differentiate from other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without context or conditions.
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 provides no behavioral details beyond the fact that it updates. The annotation only provides idempotentHint, but the description itself does not disclose whether the update is partial or full replacement, what happens if the question does not exist, or any side effects. This is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundancy, making it concise and front-loaded. However, it is so brief that it under-specifies important context, though the sentence itself is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested question object and multiple required IDs, the description is too minimal to be complete. It lacks information about update semantics, error behavior, or relationship to quiz/course structure. The schema helps with parameters, but the description does not address operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four required parameters with descriptions, so the schema carries most of the parameter meaning. The description adds no additional parameter guidance, but since schema coverage is 100%, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'existing question in a quiz,' clearly indicating a modification operation. It distinguishes from creating or deleting by the word 'existing' and the resource type 'question.' However, it does not explicitly differentiate from sibling tools like update-quiz-question-group or update-quiz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool instead of create-quiz-question, delete-quiz-question, or update-quiz. There is no context about prerequisites or typical workflows, leaving the agent to infer context 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 only provide destructiveHint=false, and the description does not disclose any additional behavioral traits such as permissions, defaults, side effects, or return values. It merely restates the create action and the required courseId, adding no behavioral context beyond what the name and schema 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the core purpose. Every word adds value, and the exception note 'All fields optional except courseId' is useful, making it highly concise without wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates an assignment group with seven parameters, no output schema, and sparse annotations, the description is too minimal. It does not explain what an assignment group is, what the various fields do, or what the caller should expect in response. This is a significant gap for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only courseId is described). The description does not explain any of the six undocumented parameters (name, rules, position, group_weight, sis_source_id, integration_data). The statement 'All fields optional except courseId' merely echoes the schema's required field and does not compensate for the lack of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('assignment group (bucket) in a course'), which clearly distinguishes it from sibling tools like create-assignment or list-assignment-groups. The parenthetical 'bucket' adds immediate conceptual clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the name and 'create a new assignment group' strongly imply its use case. The only usage guidance is 'All fields optional except courseId,' which is a parameter constraint rather than a contextual usage guideline.
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 fact that it creates a quiz. The only annotation, destructiveHint: false, is not contradicted, but the description does not disclose any side effects, prerequisites, or return behavior, leaving the agent without insight into what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the essential purpose without any wasted words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is too sparse. It does not explain what the response will be, any constraints on parameters (beyond schema), or how the created quiz is integrated into the course. The schema covers parameter semantics, but the overall context for the operation is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a brief description. The tool description itself adds no parameter-specific meaning beyond the schema, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Create') and resource ('a new quiz in a course'). It distinguishes itself from sibling tools like update-quiz, delete-quiz, and list-quizzes by explicitly indicating 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. The description simply states the action without mentioning situations where another tool (e.g., update-quiz, create-quiz-question) would be more 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?
The description adds no behavioral context beyond the idempotentHint annotation. It does not explain what happens if a rubric is already attached, whether it replaces the existing rubric, or any side effects. With annotations present, the bar is lower, but the description still fails to disclose the operation's behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the purpose. There is no unnecessary information, making it perfectly concise for the tool's simple functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 simple string parameters, no output schema) and the idempotency annotation, the description is minimally viable. However, it omits key contextual details such as the effect on an existing rubric attachment, which an agent would likely need to know for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a clear description (e.g., 'The ID of the course'). The tool description does not add any additional semantic meaning beyond the schema, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach a rubric to an assignment' clearly states the verb (attach), resource (rubric), and target (assignment). It is specific and unambiguous, and there is no sibling tool with a similar purpose, so it distinguishes itself effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this should be used instead of updating the assignment or list-rubrics, nor does it describe any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, non-destructive operation (destructiveHint=false). The description adds that all fields are optional except courseId, which clarifies the required input. However, it does not disclose side effects, default values, or any post-creation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary purpose. It contains no wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, minimal annotations), the description is too sparse. It does not cover parameter semantics, expected response, permissions, or how fields interact. The schema partially lists properties but lacks descriptions for most, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only courseId is described). The description clarifies that all other fields are optional but does not explain the meaning of name, due_at, published, grading_type, points_possible, submission_types, or assignment_group_id. It only minimally compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a new assignment') and the target resource within a specific context ('in a course'). This distinguishes it from sibling tools like create-assignment-group and update-assignment, which have different resources or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as update-assignment for modifications or delete-assignment for removals. It does not mention exclusions, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already indicates the destructive nature, but the description adds no additional behavioral context such as irreversibility, permission requirements, or effects on associated data. It merely restates the action without augmenting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence—'Delete a question from a quiz'—with no wasted words or unnecessary structure. It is succinct and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with clear parameters and a destructiveHint annotation, the description is minimally viable. However, it lacks any caveats about consequences or context, so completeness 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions fully cover all three parameters (courseId, quizId, questionId), so the description does not add parameter-level meaning. Baseline 3 applies since 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a question from a quiz' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete-quiz or delete-quiz-question-group. It states exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete-quiz or delete-quiz-question-group. It doesn't mention prerequisites, exclusions, or context, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals that this is a safe read operation. However, the description adds no behavioral context beyond that—such as pagination behavior, whether all assessments are returned at once, how the 'anonymous' flag affects results, or any access requirements. The description does not disclose anything about side effects or return characteristics, so it adds little over the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no unnecessary words or repetition, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no output schema. The description and schema collectively cover the essential inputs and read-only nature, but the response format is unspecified. Since there is no output schema, the absence of any mention of return structure or pagination leaves a gap. The description is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, with each parameter described (courseId, assignmentId, and anonymous with default and purpose). The description does not add further meaning to these parameters beyond what the schema already provides. Baseline 3 is appropriate since the schema handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all rubric assessments for an assignment' uses a specific verb ('list') with a clear resource ('rubric assessments') and scope ('for an assignment'). This distinguishes it from sibling tools like list-rubrics (which lists rubrics themselves) and list-assignment-submissions (which lists submissions). The word 'all' signals the full set, matching the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose this over list-rubrics or list-assignment-submissions, nor does it state any excluded scenarios. The only context is the assignment scope, which is already evident from the parameters.
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 destructiveHint annotation already communicates that this is a destructive operation. The description adds no extra context such as permanence, cascading effects on questions, or any other behavioral details, so it does not go beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and front-loaded, efficiently stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema, the description is under-specified. It does not mention whether the deletion is permanent, what happens to associated content, or what the response indicates, leaving the agent without full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (quizId and courseId) with 100% coverage. The description adds no additional meaning beyond what the schema already provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete a quiz from a course.' It uses a specific verb and resource, and it is distinct from sibling tools like delete-quiz-question and delete-quiz-question-group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to remove a quiz, but it does not explicitly state when to use it versus alternatives. Since no alternative for deleting a quiz exists among siblings, the guidance is adequate but minimal.
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 readOnlyHint annotation already declares that this is a read-only operation, and the description does not contradict it. However, the description adds no additional behavioral context—it does not mention return format, potential errors, or any side effects. With the annotation covering the safety aspect, the description provides no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of seven words. It is front-loaded with the verb and resource, contains no unnecessary information, and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the agent cannot infer the return value from structured data. The description also does not state that it returns a full question object or describe any edge-case behavior. For a fetch operation, this is a notable gap, even though the tool is simple and the annotations provide some safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (courseId, quizId, questionId) with clear descriptions, achieving 100% coverage. The description adds no parameter-level meaning beyond what is already in the schema, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'fetch' and identifies the resource as 'a single question from a quiz.' This clearly distinguishes it from sibling tools like list-quiz-questions (which fetches multiple questions) and get-quiz (which fetches the quiz itself). The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific question by ID is needed, but it does not explicitly mention alternatives or when to avoid this tool. The singular 'a single question' and the questionId parameter suggest a targeted lookup, but no exclusions or comparisons to siblings like list-quiz-questions 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?
The annotations declare readOnlyHint: true, so the read-only nature is already covered. The description adds that it fetches statuses and comments, but does not disclose other behavioral aspects such as pagination or rate limits. This is acceptable given the annotation, but not particularly rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that gets straight to the point. It is front-loaded with the key action and resource, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with well-documented parameters and no output schema, the description is sufficient to convey its purpose and expected return content. However, it doesn't address the potential ambiguity with list-section-submissions, which would have made it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has comprehensive descriptions for all three parameters (100% coverage). The description does not add any additional meaning or clarify parameter semantics 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('fetch') and clearly identifies the resource ('submission status & comments') and scope ('every student... for an assignment'). It distinguishes from grading/comment-posting tools, but does not explicitly differentiate it from the similar sibling tool 'list-section-submissions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like list-section-submissions. The description simply states what the tool does without providing any context about appropriate use cases 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 annotation `readOnlyHint: true` already declares this as a safe read operation. The description adds no further behavioral context such as pagination, ordering, or error behavior. It simply restates the purpose without disclosing any additional traits beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant details. It efficiently conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, read-only annotation), the description is sufficient for an agent to understand the tool's basic function. However, it lacks details about return format (e.g., fields included) or pagination, but these are not critical for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a complete description of the single parameter (`courseId`), so the baseline is 3. The description does not add extra meaning beyond what the schema already states, such as format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all quizzes in a course, using a specific verb (`Get a list`), resource (`quizzes`), and scope (`in a course`). This distinguishes it from related tools like `get-quiz` (single quiz) and `create-quiz`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., `get-quiz` for a single quiz) or any prerequisites. The phrase 'in a course' implies a course context, but there is no explicit when/when-not guidance.
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 annotation already provides readOnlyHint=true. The description adds little beyond that: 'complete list' is a vague scope qualifier, and there is no mention of pagination, response format, or privacy defaults. These behaviors are only implicit in the schema, not disclosed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and clearly states the purpose. There is no redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature and rich schema with 100% parameter coverage, the description is mostly sufficient for an agent to invoke the tool. However, it lacks explicit mention of the return structure or any usage caveats, though these are not critical for such a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it only implicitly references courseId via 'a specific course' and does not elaborate on the anonymous or includeEmail parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Get' with a specific resource ('complete list of all students') and scope ('enrolled in a specific course'). It distinguishes the tool from siblings that operate on modules, assignments, or courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply restates the function without contextual advice, such as recommended use cases 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?
The description does not disclose any behavioral traits beyond the annotation destructiveHint=false. It does not mention whether the announcement is immediately visible, who can see it, whether it can be edited or deleted later, or any side effects. Since there is no output schema, the description should carry more weight but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the core purpose without any wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the 100% schema coverage, and the presence of a non-destructive annotation, the description is nearly complete. However, it omits minor contextual details such as whether the announcement is published immediately or if there are permission requirements, but these are not critical for a basic post operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters (courseId, title, message). The description adds no additional meaning 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('post'), the resource ('announcement'), and the target ('a specific course'). It is specific and unambiguous, and there are no sibling tools with similar functionality, so it distinguishes itself effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While there are no other announcement-related sibling tools, the description does not mention any prerequisites, scheduling, or exclusions, leaving usage context entirely 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?
The annotations provide idempotentHint: true, and the description does not contradict this. However, the description adds limited behavioral context beyond telling the agent that all fields except identifiers are optional, which hints at partial-update semantics. It does not disclose side effects, permissions, or behavior when fields are omitted, relying on the annotation for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately identifies the tool's purpose and the key parameter requirement. It is appropriately concise, though it omits details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 20% schema coverage, and no output schema, the description is far too minimal. It does not list updatable fields, expected input formats, or any return behavior, making it inadequate for an agent to confidently invoke the tool with correct arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (courseId and assignmentId), leaving all other 8 parameters undocumented. The description only repeats the requirement that non-identifier fields are optional, which the schema already encodes. It does not explain formats (e.g., due_at, grading_type) or valid values, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update an assignment.' This specific verb+resource combination distinguishes it from siblings like create-assignment, delete-assignment, and get-assignment. It also adds clarity by noting that all fields are optional except courseId and assignmentId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to modify an existing assignment) but does not explicitly differentiate it from alternatives like bulk-update-assignment-dates or list-assignments. There are no exclusions or alternative recommendations, leaving the agent to infer usage from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: false, and the description's 'create' action is consistent with that. However, the description does not add any additional behavioral context beyond the annotation, such as side effects or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description is relatively thin. It does not mention return values, required parameters, or how the parameters relate to the creation process, though the schema and annotations provide some support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, so the schema already documents each parameter fully. The description adds no extra parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (create) on a specific resource (module) within a course, which distinguishes it from sibling tools like update-module, delete-module, and list-modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives such as create-module-item or update-module; it merely states the action without 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 include only destructiveHint: false, which the 'create' action already conforms to. The description adds no further behavioral context such as return values, error handling, idempotency, or effects on existing data. It provides no transparency beyond the annotation, missing an opportunity to clarify that the question is appended or that the quiz must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: 'Create a new question in a quiz.' It is concise, front-loaded, and contains no fluff or redundant information. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description is minimally adequate. It clarifies the action but doesn't explain response format, validation rules, or the necessity that the quiz already exists. The schema and annotations cover parameter details and non-destructiveness, but the absence of any behavioral or return-value context leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for courseId, quizId, and question. The tool description does not add any meaning beyond the schema, which is acceptable since the schema already fully documents each parameter. The baseline of 3 applies because the description is not needed to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new question in a quiz' uses the specific verb 'create' and clearly identifies the resource ('new question in a quiz'). It distinguishes itself from sibling tools like 'update-quiz-question' (update), 'delete-quiz-question' (delete), and 'create-quiz' (create quiz).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a question, but it doesn't explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, it doesn't say 'Use this to add a new question to an existing quiz' or 'To modify, use update-quiz-question.' The intent is clear but not explicitly contrasted with 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?
The annotation readOnlyHint=true covers the safety profile, and the description is consistent with it. However, the description adds no additional behavioral context, such as return format, pagination, error conditions, or what 'statistics' includes. It merely restates the purpose without enriching the behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get', and contains no unnecessary words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only getter with well-documented schema and annotations, but without an output schema, the description does not explain what statistics are returned or how includePointDistribution affects the output. It is adequate but leaves some gaps in expected information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no extra parameter semantics 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves statistics for rubric assessments on an assignment. The verb 'get' and resource 'statistics for rubric assessments' are specific, and the scope ('on an assignment') is clear. It distinguishes from siblings like list-rubric-assessments by focusing on aggregate statistics rather than individual assessments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when statistics are needed, but provides no explicit guidance on when to use this tool versus alternatives such as list-rubric-assessments or list-assignments. There is no mention of exclusions, alternatives, 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?
The description adds that file downloads are optional and that it returns submission details, file information, and optionally file content. This supplements the readOnlyHint annotation by clarifying the retrieval behavior, but it does not discuss rate limits, authentication, or the impact of the anonymous parameter, providing only limited additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence states the action and resource, and the second clarifies the return payload, ensuring front-loaded clarity and efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and five parameters, the description covers the core functionality and relies on the schema for parameter details. However, it does not mention default behaviors (e.g., downloadFiles defaults to false, anonymous defaults to true) nor does it guide the agent on when to prefer this tool over closely related siblings, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full 100% description coverage for all five parameters, so the baseline is 3. The description only indirectly references downloadFiles via 'optional file downloads' and does not clarify the anonymous parameter or the required IDs, adding minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'a student's submission with attachment metadata and optional file downloads.' This distinguishes it from sibling tools like get-submission-file-info (metadata only) and download-submission-file (content only), making its combined purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get-submission-file-info or download-submission-file. The description does not mention any exclusions, preferred scenarios, or explicit alternatives, leaving an agent 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?
With only destructiveHint=false provided, the description carries the burden of disclosure, but it only states the action without mentioning side effects, permissions, or whether the comment is appended or replaces existing ones. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and object. Every word adds value, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with no output schema or nested objects, but the description lacks context about return behavior, potential errors, or how it differs from closely related tools like grade-submission. It is minimally sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four required parameters, so the schema already explains each parameter. The tool description adds no additional semantic meaning beyond what is in the schema, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Attach') and resource ('comment on a student's submission'), clearly identifying the tool's function. It distinguishes from sibling tools like grade-submission, which handles grading rather than feedback comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (targeted feedback on a submission) but provides no explicit guidance on when to use this over alternatives, or when not to use it. It does not mention exclusions or prerequisite conditions.
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 only annotation is idempotentHint=true; the description adds no behavioral context beyond the basic action. For a mutation operation that likely overwrites current page content, it does not disclose side effects, irreversibility, or the need for revision ownership, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the verb and resource, no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter schema and idempotency annotation, the description is minimally adequate, but it lacks usage differentiation from sibling page-editing tools and doesn't mention the destructive nature or outcome. No output schema means some return-value context would help, though not critical for a revert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for courseId, pageUrl, and revisionId, so the schema does the heavy lifting. The description adds no additional parameter meaning; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('revert') and resource ('page') with a clear target ('previous revision'), distinguishing it from siblings like update-page-content, patch-page-content, and apply-page-changes. It states exactly what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of rolling back a page to an earlier revision, but provides no explicit when/when-not guidance or alternatives. It does not mention that this should be used instead of update-page-content/patch-page-content for restoring historical state.
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 annotation idempotentHint: true already indicates idempotency, but the description adds no behavioral details beyond that. It does not specify whether the update replaces the entire quizGroup object or merges with existing fields, nor does it mention error conditions or permissions. Since the annotation covers the safety profile, the description provides 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, direct and front-loaded with the action verb. It contains no filler or redundant information, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a rich schema and idempotency annotation, the description is minimal but not entirely inadequate. However, it fails to clarify whether the quizGroup object requires all fields or only changed fields, which is a meaningful gap. No output schema exists, so return value explanation is not expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, so the baseline is 3. The description does not add any meaning beyond the schema; it merely names the action without elaborating on the quizGroup object or its fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update an existing question group in a quiz.' It uses a specific verb ('update') and resource ('question group'), and the word 'existing' distinguishes it from creating or deleting a group. This clearly separates it from sibling tools like create-quiz-question-group and delete-quiz-question-group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an already-existing question group, but there is no explicit guidance on when to use this tool instead of alternatives. No alternatives or exclusions are mentioned, so the agent must infer context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint=false, which aligns with the non-destructive nature of creating. The description adds minimal behavioral context beyond the tool name, such as implying a new group is added without overwriting. It does not describe outcomes, prerequisite validation, or return values, but with annotations covering the safety profile, the description is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that conveys the essential function without any redundancy. It is appropriately minimal for a straightforward create operation, earning full marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with three parameters, a nested object, and no output schema. The description is clear enough for an agent to invoke the tool, but it lacks guidance on expected return values or preconditions (e.g., course and quiz must exist). Given the absence of an output schema, a bit more context would improve completeness, but the current level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter and nested property described directly in the input schema. The description itself adds no additional parameter meaning, and the baseline of 3 applies because the schema fully documents the required fields (courseId, quizId, quizGroup with name, pick_count, question_points).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new question group in a quiz'), with a specific verb+resource pattern. It naturally distinguishes from sibling tools like update-quiz-question-group, delete-quiz-question-group, and list-quiz-question-groups by indicating the creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a quiz question group but does not explicitly state when to use it versus alternatives (e.g., update or delete). No exclusions or alternative tools are mentioned, relying on the verb 'create' to convey context, which is adequate 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation is present and matches the 'Delete' wording, but the description adds no further behavioral disclosure. It does not say whether deleting the group also deletes its questions, whether the operation is irreversible, or what permissions are required—important details for a destructive action. This is a clear gap beyond what the annotation already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately states the action and target, making it easy for an agent to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and all parameters are well-defined, but the description leaves ambiguity about the relationship between a question group and its questions: does deletion cascade to contained questions? This is a meaningful context gap, though for a basic delete operation with a destructiveHint annotation it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (courseId, quizId, groupId) are fully described in the input schema with 100% coverage, so the schema carries the parameter semantics. The description does not add parameter details, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a clear, specific statement: 'Delete a question group from a quiz.' It names the action (delete), the resource (question group), and the parent context (quiz), and it can be distinguished from sibling tools such as delete-quiz-question or delete-quiz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the appropriate context: use this tool when a question group needs to be removed from a quiz. It doesn't explicitly mention alternatives or when-not-to-use, but the resource-specific wording provides sufficient guidance for this simple CRUD operation.
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 readOnlyHint=true annotation already indicates a safe read operation. The description adds that it returns all submissions for a section, but lacks details about pagination, ordering, or response format. With annotations covering the safety profile, the description adds some value but not rich 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with comprehensive schema and annotations, the description is adequate but not fully complete. It does not mention return value structure or whether submissions include grades/student info, which could be relevant since no output schema is provided. However, it covers the essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are documented in the schema. The description itself does not add meaning beyond the schema, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all student submissions for a specific assignment filtered by section'. It distinguishes from sibling 'list-assignment-submissions' by including the section filter, making its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when section-filtered submissions are needed, but it does not explicitly state when to use this tool versus alternatives like 'list-assignment-submissions'. No direct exclusion or alternative mention 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 annotation declares idempotentHint, but the description adds no additional behavioral context such as whether unspecified fields are left unchanged. It doesn't mention side effects like moving an item removing it from the original module, so it leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all updatable attributes with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and no output schema, the description is too thin. It doesn't explain partial update behavior, required parameters, or return value, leaving significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description merely lists parameter names without explaining semantics or dependencies. For example, it doesn't clarify the relationship between completion_requirement_type and completion_requirement_min_score, or the effect of new_tab on external URLs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Update an existing module item' and enumerates the fields (title, position, indent, external URL, published state, completion requirement, move). This clearly distinguishes it from sibling tools like create-module-item or delete-module-item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing module items, but doesn't explicitly state when to prefer this over alternatives like update-module or get-module-item. It provides clear context without explicit 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?
The description adds no behavioral detail beyond the idempotentHint annotation. It does not mention what happens to unspecified dates, whether the operation is atomic, or any partial failure behavior. With the annotation already indicating idempotency, the description adds minimal additional transparency, but does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately conveys the tool's purpose and scope, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity (array of objects, optional fields), the description is too sparse. It does not explain return values (no output schema), error handling, or how partial updates are treated. An agent would need more context to understand the full behavior of this bulk operation, especially given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (100% coverage), so the baseline is 3. The description's mention of 'due/unlock/lock dates' aligns with the schema fields, but adds no additional semantic meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('bulk update') and the specific resources ('due/unlock/lock dates for assignments in a course'). It distinguishes from sibling tools like update-assignment (which likely updates a single assignment) and delete-assignment, making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use when needing to update date fields across multiple assignments simultaneously. However, it does not explicitly mention alternatives or when not to use, such as when only updating a single assignment or non-date fields. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'archive' beyond the destructiveHint annotation, clarifying that deletion is not permanent. This provides useful behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with only two parameters and no output schema, the description is nearly complete. It names the action, the resource, and the archival behavior, which is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (courseId, assignmentId) are already well-described in the schema. The tool description adds no additional parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('an assignment from a course'), with the parenthetical 'archive' providing a specific nuance. This distinguishes it from other delete tools like delete-quiz and delete-module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., update-assignment, list-assignments). The description simply states what it does, leaving 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?
The destructiveHint annotation already communicates the destructive nature, and the description does not contradict it. However, the description adds no behavioral context beyond the annotation—no mention of permanence, cascading effects, or permission requirements. It adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and resources. Every word contributes value, with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the delete operation, the fully described schema, and the destructiveHint annotation, the description is sufficient. It does not elaborate on return values or edge cases, but for a straightforward CRUD tool with complete structured metadata, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (courseId, moduleId, itemId), achieving 100% coverage. The tool description itself does not add any parameter-specific meaning, so it remains 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with a clear resource ('item') and context ('from a module'). This distinguishes it from siblings like get-module-item, create-module-item, and update-module-item, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (delete an item from a module) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as delete-module for deleting an entire module. Context is clear but exclusions and alternatives are 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?
The readOnlyHint annotation already indicates a safe read operation, and the description aligns with that. However, the description adds no additional behavioral context such as error handling, return format, or data scope beyond what annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of six words, with no redundant information. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read operation with three well-documented parameters and a read-only annotation, the description is mostly complete. However, the absence of an output schema means the description could clarify what 'details' includes, making the minor gap acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (courseId, moduleId, itemId) has a clear description. The tool description does not add any additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get details' and the target 'a single module item', which distinguishes it from list-module-items and other sibling tools. The use of 'single' adds specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like list-module-items. Usage is implicitly understood from the name and description, but no exclusions or alternative contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint=true annotation and adds the nuance that it returns 'metadata' rather than full quiz details. However, it does not disclose additional behavioral aspects such as error handling, authorization, or what exactly 'metadata' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact phrase that conveys purpose without redundancy or unnecessary words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two clearly described parameters, the description is mostly adequate. However, with no output schema, it leaves the contents of 'metadata' vague, and it doesn't explicitly contrast with list-quizzes for single-item use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both quizId and courseId (100% coverage), so the description does not need to repeat them. It also adds no extra semantic meaning to the parameters; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and resource 'metadata for a single quiz', clearly identifying a single-item read operation. This distinguishes it from sibling tools such as list-quizzes (which fetches many) and get-quiz-question (which targets a 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the phrase 'single quiz'; there is no explicit guidance on when to prefer this over list-quizzes or other quiz-related tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It adds the 'all modules' scope (no filtering) and the optional inline items behavior, but these are largely evident from the schema. No additional behavioral details like pagination or limits are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does with no unnecessary words. It earns its place without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, read-only annotation, no output schema). The description covers the core purpose and optionally mentions inline items. It lacks details like return format or pagination, but these are not critical for a straightforward list operation, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both courseId and includeItems have clear descriptions. The tool description adds no extra parameter semantics beyond what the schema already provides, so it sits at the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return all modules in a course (optionally inline items)' uses a specific verb ('Return') and resource ('modules in a course'), clearly distinguishing it from sibling tools like list-module-items which handle module items. It also hints at the optional includeItems parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a list of modules, but it does not explicitly mention alternatives or exclusions (e.g., 'for item-level details, use list-module-items'). There is no explicit when-to-use or when-not-to-use guidance, so it lands at the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description is consistent with this. However, the description adds no additional behavioral context beyond the basic listing action—no mention of return format, ordering, or pagination. It neither enriches nor contradicts the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the key action and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with well-defined parameters and annotations, the description is adequately complete. It might have mentioned what revision information is returned, but it is not essential for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (courseId and pageUrl) fully described. The description adds no parameter-specific meaning; the schema already provides complete semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all revisions for a page' uses a specific verb ('list') and clear resource ('revisions for a page'), distinguishing it from sibling tools like 'revert-page-revision' and 'get-page-content'. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing revision history but provides no explicit when-to-use or alternative comparisons. It does not mention when to choose this over 'get-page-content' or 'revert-page-revision', though the purpose is self-evident.
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 toggle behavior, which is a key behavioral trait not fully captured by the annotations or schema. The annotation only provides destructiveHint=false, so the description adds that the tool flips the publish state rather than setting a specific 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param toggle tool with no output schema and a clear annotation, the description is sufficient. It fully explains the action without unnecessary detail, though it omits potential side effects or prerequisites, which are likely not critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with clear descriptions ('The ID of the course' and 'The ID of the module'). The description adds no extra parameter information, so it is at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (publish/unpublish) on a specific resource (module) and explicitly notes 'toggles the current published state,' distinguishing it from update-module or delete-module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like update-module or create-module. There is no mention of exclusions, conditions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With the idempotentHint annotation true, the safety of retries is known. The description adds context about accepting the 'full new body', implying page body replacement, but it does not disclose other potential side effects (e.g., whether unspecified fields are reset, or if there are permission requirements). It provides some value beyond annotations but lacks richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core action, and contains no filler. It is well-structured and front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and is a write operation. The description covers the basic purpose and workflow, but it omits details about return values, error cases, and what happens to optional fields. It is adequate for a simple write tool but lacks thoroughness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds slight nuance by specifying that newContent is the 'full new body', which clarifies its role, but it does not significantly enhance understanding of other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Write revised HTML content to a Canvas page') and identifies the specific resource. It also distinguishes itself from sibling tools by noting it is the 'second step after patch-page-content', which differentiates it from related page edit 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'Intended as the second step after patch-page-content.' This tells the agent when to use it, though it does not explicitly state when not to use it or mention alternative actions such as update-page-content.
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 annotation already provides readOnlyHint=true, indicating a safe read operation. The description adds that the tool returns 'download URLs and metadata,' which is useful context but does not disclose any additional behavioral traits (e.g., prerequisites, rate limits, or side effects). Since the operation is read-only and lacks destructive behavior, the description is minimally 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (~20 words) that front-loads the action and resource. It contains no redundant information and effectively communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 1-parameter, read-only tool. The description, combined with the schema and readOnlyHint annotation, sufficiently covers the tool's purpose, input, and output type ('download URLs and metadata'). There is no output schema, but the description provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the sole parameter fileId is described as 'The ID of the file to retrieve information for.' The tool description does not add further parameter details. With full schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and a specific resource ('detailed information about a specific file attached to a submission'). It also mentions the key output ('download URLs and metadata'), which distinguishes it from related siblings like download-submission-file (which downloads the file) and get-submission-documents (which likely lists documents). The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving file metadata and URLs rather than downloading the file content, but it does not explicitly state when to use this over alternatives (e.g., 'for actual content, use download-submission-file'). No exclusions or conditions are provided. Usage context is implied but not directly 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, covering safety. The description adds the 'all questions' scope, implying no filtering or pagination, but doesn't discuss ordering, response format, or rate limits. With annotations, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence ('Get a list of all questions in a quiz') with no filler or redundant information. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with clear parameters and readOnlyHint, the description is minimally sufficient. However, with no output schema, it doesn't specify the structure of the returned questions, which could be a gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both required parameters (courseId and quizId). The description adds no additional parameter meanings or syntax, so it meets the baseline for adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get a list') and identifies the resource ('all questions in a quiz'). It clearly distinguishes from siblings like 'get-quiz-question' (single question) and 'list-quiz-question-groups' (question groups, not questions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need all questions for a quiz. While it doesn't explicitly state alternatives or when-not-to-use, the sibling tools' names imply other use cases (e.g., 'get-quiz-question' for a single question).
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=false, and the description aligns with that (creating, not destroying). The description adds the type constraint but does not disclose potential side effects, such as module reordering or required content references. It provides baseline transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly scoped sentence followed by a type list. It wastes no words and immediately conveys the core operation. It is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's rich parameter descriptions, the brief description is adequate for understanding what the tool does. It could have included conditional guidance (e.g., content_id required for File/Quiz/Assignment) but the schema already provides that. The tool has no output schema, so no return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including per-type requirements. The description repeats the type enum but adds no new parameter semantics beyond the schema. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new item') and the target resource ('a module'), with an explicit enumeration of allowed item types. This distinguishes it from sibling tools like create-module, update-module-item, and delete-module-item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for adding new items to modules. It does not explicitly name alternatives for updating or deleting module items, but the context makes the usage obvious. No exclusions are given, so it earns a 4 rather than 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 adds value beyond the destructiveHint annotation by specifying that deletion is permanent and cascades to all module items. This is important behavioral context not conveyed by the annotation alone, though it does not mention permissions or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, the first stating the primary action and the second adding the critical consequence. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description covers the essential purpose and a key behavioral trait (permanence/cascading). It could mention error conditions or prerequisites, but overall it is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already fully cover both parameters (courseId and moduleId), so the description does not need to add parameter-level detail. The description adds no additional meaning beyond the schema, but this is acceptable given 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (delete), the resource (a module), and the scope (from a course). It also differentiates from siblings like delete-module-item by noting it removes all module items, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for deleting an entire module, but does not explicitly state when to use it versus alternatives like delete-module-item for single items. The caution about permanence gives indirect context, but no explicit when/when-not 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?
The annotation readOnlyHint=true already indicates a safe read operation, and the description adds context about the specific metadata fields returned. However, it does not disclose behaviors like error handling, response shape, or potential variations such as whether rubric is always included, so it stays at a baseline level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and resource, followed by a parenthetical list of examples. Every word adds value, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with two parameters and no output schema, the description provides sufficient context: it states the purpose, gives example return fields, and is complemented by the readOnlyHint annotation. It does not cover error cases or exact response structure, but those are not critical for such a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already explains courseId and assignmentId. The description does not add new semantic meaning beyond reinforcing that it targets a single assignment, which keeps it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with a clear resource ('metadata for a single assignment') and lists example contents (due date, points, rubric, submission types), which precisely distinguishes it from sibling tools like list-assignments, create-assignment, or delete-assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving a single assignment's metadata, which establishes the primary use case. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no extra behavioral context beyond that, such as response format, error handling, or exclusions (e.g., that pages are not included). It meets the minimal bar set by the annotations but does not enrich the agent's understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single short sentence: 'Get details for a single ePortfolio by ID.' It is front-loaded with the verb and resource, contains zero filler words, and every word contributes to the meaning. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description suffices: it identifies the resource and the lookup key. It could be enhanced by clarifying what 'details' includes (e.g., whether it encompasses all attributes or excludes pages), but given the sibling 'get-eportfolio-pages' exists, the agent can infer some separation. Overall, complete enough for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the only parameter 'eportfolioId' is described as 'The ID of the ePortfolio'. The description simply rephrases this as 'by ID', adding no new meaning. With high schema coverage, the baseline of 3 is appropriate; the description does not compensate with additional parameter-level context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get details for a single ePortfolio by ID', using a specific verb ('Get') and resource ('details for a single ePortfolio'). It distinguishes itself from siblings like 'list-eportfolios' (plural) and 'get-eportfolio-pages' (which targets pages), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a specific ePortfolio when you have its ID, which is clear context. However, it does not explicitly mention alternatives like 'list-eportfolios' for finding IDs or note when not to use it, so it misses the full 'when/when-not' guidance that would earn a 5.
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 readOnlyHint annotation already signals a safe read operation, and the description aligns by saying 'Get a list'. The description adds context by mentioning that submission status for students is included, but it doesn't disclose any further behavior such as pagination, default anonymization, or output structure, so it doesn't go beyond the annotation significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and resource, with no 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with detailed schema and annotations, the description covers the core functionality well. It mentions the scope (all assignments in a course) and the key output feature (submission status). However, it doesn't mention optional filtering (studentId, includeSubmissionHistory) or the default anonymization behavior, but those are covered in the schema, so the description provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description itself doesn't add any information about parameters; the schema already documents courseId, anonymous, studentId, and includeSubmissionHistory with clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get a list' with the resource 'assignments' and scopes it to 'in a course', while specifying the additional value of 'submission status for students'. This clearly distinguishes it from siblings like get-assignment (single assignment) and list-assignment-submissions (submissions only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need all assignments in a course with student submission status, use this tool. It provides clear context (course, assignments, submission status) but does not explicitly mention alternatives or exclusions, so it earns a 4 rather than a 5.
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 readOnlyHint annotation already indicates this is a safe read operation. The description adds useful context about item types (pages, quizzes, files, etc.) but does not disclose other behavioral traits such as pagination, ordering, or return format. This partial additional context warrants a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of filler. It communicates the essential information efficiently, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with only two required parameters and no output schema. The description adequately covers the tool's purpose and scope, including examples of item types. While it omits details like pagination or return structure, the tool's simplicity and the readOnlyHint allow a score of 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, each with clear descriptions ('The ID of the course', 'The ID of the module'). The description reinforces the use of moduleId but adds no syntactic or format details beyond the schema. Given the high 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list'), resource ('its items'), and context ('Given a module ID'), clearly distinguishing it from sibling tools like list-modules (which lists modules) and get-module-item (which fetches a single item). The examples of item types (pages, quizzes, files) further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the usage context: when you have a module ID and need its items. It does not explicitly mention alternatives or when not to use it, but the context is unambiguous. Sibling tool names like create-module-item and delete-module-item make the distinction obvious, so a 4 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 annotation readOnlyHint already declares the tool's safe read-only nature. The description adds scope ('all question groups') but doesn't disclose return format, ordering, pagination, or other behavioral traits. This is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence that is front-loaded and contains no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with a well-defined schema, the description adequately covers the essential function. It doesn't mention return format, but no output schema exists to shift the burden, and the operation's simplicity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (courseId and quizId) with 100% coverage, so the description doesn't need to add parameter-specific meaning. It provides no extra detail, which matches the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('get a list'), resource ('question groups'), and scope ('in a quiz'). It effectively differentiates from siblings like get-quiz-question-group (singular) and create/update/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing all question groups for a given quiz, which is distinct from fetching a single group. It doesn't explicitly name alternatives, but the context is clear and no exclusions are needed for a simple read-only list.
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=true, and the description aligns by using 'List' and 'Returns'. It adds value by specifying the exact return fields (id, position, name, content, timestamps), which is useful because there is no output schema. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the resource, and the return contents. Every word is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list tool with one parameter and no output schema. The description adequately covers the tool's behavior and return values, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'eportfolioId' parameter (100% coverage), so the description does not need to repeat parameter details. It adds no extra meaning, but the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'pages in an ePortfolio', distinguishing it from the sibling 'list-pages' by specifying the ePortfolio scope. It also enumerates the returned fields, making the tool's purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ePortfolio pages but does not explicitly contrast with sibling 'list-pages' or other alternatives. There is no when-to-use or when-not-to-use guidance, so the usage context is only inferred.
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 mark this read-only, so the description doesn't need to restate safety. It adds valuable behavioral and output context by enumerating the returned fields and emphasizing the full HTML body, which is not provided by the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with a clear action, resource, lookup method, and a tight list of return values. Every word serves a purpose and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description is complete: it explains how to look up the page and exactly what to expect in the response. Since the annotation declares read-only behavior and the schema fully documents the parameters, no additional context is needed. The lack of an output schema is compensated by the explicit field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters fully, including the meaning of pageUrl as a URL slug. The description only echoes pageUrl's schema description and does not add constraints, defaults, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get the full content of a page by URL slug,' clearly specifying the action, resource, and lookup method. It lists the concrete return fields (title, slug, page ID, published status, last-updated timestamp, HTML body), which distinguishes it from sibling tools like list-pages or update-page-content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full content' implies this is the detailed read tool, and the requirement of a URL slug indicates when it applies. However, there is no explicit when-to-use versus alternatives, no mention of when not to use it, and no reference to sibling tools like list-pages or list-page-revisions.
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 annotation readOnlyHint=true already discloses this as a safe read operation, and the description's 'Fetch' aligns with it. The description adds no additional behavioral context beyond scope (single item), which is acceptable for a simple get, though not-found or error behavior is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource with no filler. Every word contributes to understanding, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with complete schema descriptions and a readOnly annotation, the description provides sufficient context. No output schema exists, but the intent is clear and the tool's simplicity means no additional details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (courseId, quizId, groupId) already have complete descriptions in the schema, so the description does not need to add meaning. It adds nothing beyond the schema, meriting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the target ('a single question group from a quiz'), using a specific verb and resource scope that distinguishes it from sibling tools like list-quiz-question-groups and delete-quiz-question-group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Fetch a single' implies the tool is for retrieving one specific question group, contrasting with the sibling list endpoint, but it does not explicitly name alternatives or exclusions. This provides clear context without meeting the highest explicit-guidance bar.
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=true, and the description aligns with that. The description adds the specific return fields, but doesn't disclose extra behavior like pagination or authentication requirements. Given annotation coverage, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter, no output schema, read-only annotation. The description covers the core functionality and return value, making it complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter courseId is 100% covered by the schema description, so the description adds no additional semantics. At baseline 3, it's sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (rubrics in a course), and the returned fields (title, ID, description). This distinguishes it from sibling tools like list-rubric-assessments or get-rubric-statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is clear for when to use it: to enumerate rubrics in a course. It doesn't explicitly discuss alternatives, but the sibling context (e.g., list-rubric-assessments) implies this is for the rubric definitions themselves. It sets clear context but no exclusions.
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 idempotentHint annotation already conveys that repeated calls are safe. The description adds valuable context about the page content (design standards, accessibility, formatting practices) and location (URL slug). It does not disclose overwrite behavior for existing slugs, but the idempotent hint mitigates the risk. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every sentence adds useful information. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, the content it includes, and where it creates the page. With an idempotent hint and no output schema, it lacks details on return values or what happens if the slug already exists. Still, it is mostly complete for a creation tool with clear parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the schema already documents each parameter. The description repeats the default slug but adds no extra meaning beyond what the schema provides, such as the format for customBranding or the exact effect of includeExamples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate and save'), the resource ('Canvas styleguide page'), and its content ('design standards, accessibility guidelines, and Canvas-specific formatting best practices'). It also specifies the URL slug behavior, distinguishing it from sibling tools like get-styleguide (retrieval) and update-page-content (editing existing pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear enough to imply when to use the tool: when a styleguide page needs to be created. However, it does not explicitly mention alternatives or exclusions, such as using get-styleguide for reading or update-page-content for modifying the page. The context is solid but could be more explicit about 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 declare readOnlyHint=true, but the description adds value by specifying the exact return fields (title, URL slug, page ID, published status) and noting it returns all pages. This is useful behavioral context beyond the annotation, though it omits pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action ('List all pages in a course') and concisely lists the returned fields. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and a readOnly annotation, the description is adequately complete. It returns all pages and specifies the response fields, which is sufficient for an agent to invoke the tool correctly. Minor omissions like pagination are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter courseId, describing it as 'The ID of the course'. The description does not add further meaning beyond the schema's baseline, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'pages in a course', distinguishing it from sibling tools like list-modules and list-assignments. It also specifies the return fields, leaving no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'in a course' indicates when to use it, and the resource name 'pages' differentiates it from other list tools. However, it does not explicitly exclude alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by listing return fields (section name, ID, SIS ID, date ranges) and explaining how includeStudentCount affects output. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and resource, followed by concise return value and parameter behavior details. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, read-only, no output schema), the description is sufficiently complete. It covers return fields and parameter behavior, though it does not mention pagination or sorting, which are not critical for a basic listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage with descriptive text for both courseId and includeStudentCount. The description's mention of includeStudentCount mirrors the schema description, adding no new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('list') and resource ('sections in a course'), distinguishing it from sibling tools like list-modules and list-pages. 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: this tool is for retrieving all sections of a course. However, it does not explicitly mention alternatives or conditions when it should not be used, but the purpose is self-evident for a simple listing 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?
The description adds valuable behavioral detail beyond the readOnlyHint annotation by explaining the return format: base64 for binary files, text for text files, with an option to force base64. This enriches the agent's understanding of what to expect without contradicting the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that first states the core action, then the return behavior. Every word earns its place, with no wasted or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description sufficiently covers the essential aspects: what it does and what the response looks like. The lack of an output schema is compensated by the explicit mention of returned content types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it merely reiterates the return format, which is also captured in the 'forceBase64' parameter description. No extra semantic layer is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Download') and resource ('actual content of a file attached to a submission'). It also distinguishes itself from siblings like get-submission-file-info by emphasizing 'actual content' rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need the file's content) but does not explicitly name alternatives or exclusion criteria. The context is clear due to the wording 'actual content', which differentiates it from similar-looking tools, though no explicit 'when not to use' is 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?
The readOnlyHint annotation already declares the tool as read-only, and the description adds useful context by specifying the return fields (title, timestamp, HTML body). While it doesn't disclose other behaviors like rate limits or auth requirements, the simple read-only nature makes this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource first, then lists the return values. There is no unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description adequately covers purpose, scope, and return format. The annotation handles safety, and the schema handles parameters, making the description complete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both slug and courseId having descriptions. The description does not add extra parameter semantics beyond what the schema already provides, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'Canvas styleguide page for a course', distinguishing it from sibling tools like get-page-content or generate-styleguide by naming the specific page type. The return fields are also listed, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving the styleguide page, which gives good context for when to use it. However, it does not explicitly mention alternatives or when not to use it (e.g., comparing with get-page-content or generate-styleguide), so it stops short of full exclusion 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?
The annotation readOnlyHint=true already signals a safe read operation. The description adds value by stating 'all' (indicating no filtering or pagination mentioned) and clarifies the resource as 'buckets'. There is no contradiction with annotations, and the behavior is straightforward for a list tool, though it does not detail return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the verb and resource, and contains zero filler. It efficiently communicates the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, a read-only annotation, and no output schema, the description is sufficient. It states what the tool does and the required context (course). No critical information is missing; the absence of return details is acceptable given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully documented (100% coverage) with a single required parameter 'courseId' described as 'The ID of the course'. The description's phrase 'in a course' aligns with this parameter but does not add any additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List all assignment groups'), the specific resource ('assignment groups (buckets)'), and the scope ('in a course'). This distinguishes it from sibling tools like 'list-assignments' and 'create-assignment-group', which target different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for listing assignment groups within a course. It does not explicitly mention alternatives or exclusions, but the phrase 'assignment groups (buckets)' helps differentiate it from related listing tools like 'list-assignments'. The usage is self-evident for a simple read-only list operation.
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?
With readOnlyHint=true already declared, the description adds meaningful context by specifying the returned fields (id, name, public flag, workflow state, timestamps) and confirming the scope is all ePortfolios for the user. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a clear verb and return field list. Front-loaded with action and scope, no filler words 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter, the description fully covers purpose, scoping, and return values. Since there is no output schema, the explicit list of returned fields fills that gap. No significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter userId is fully documented in the schema. The description's phrase 'belonging to a user' reinforces the parameter meaning but does not add new semantics or format details 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') plus resource ('ePortfolios') and scoping ('belonging to a user'), clearly distinguishing it from siblings like get-eportfolio and get-eportfolio-pages. It also lists return fields, further clarifying 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for fetching all ePortfolios for a given user, which is distinct from retrieving a single ePortfolio or its pages. However, it does not explicitly name alternatives or state when not to use it, so it falls 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 important behavioral nuances beyond the idempotentHint annotation: it states that if no body/title/editingRoles is provided, nothing is written and guidance is returned, and that showStyleguidePreview can inline the styleguide. This adds value beyond the annotation, though it doesn't detail permissions or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, followed by a conditional behavior note and an explicit alternative. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and moderate complexity, the description covers the core behavior, the no-op case, and the alternative tool. It doesn't explain what the returned 'guidance' looks like or the exact effect of partial parameters, but for an update/create operation this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some meaning by tying body/title/editingRoles together as the set triggering no-op behavior, but it doesn't provide significantly more than the schema already does. It does not fully compensate for the lack of parameter examples or additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update or create a page with new content, replacing the entire body.' This uses a specific verb and resource, and distinguishes it from the sibling patch-page-content by noting it replaces the entire body rather than making targeted edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For targeted edits to existing content, use patch-page-content instead.' This gives a clear alternative and also explains the conditional behavior when no body/title/editingRoles are provided, offering both when-to-use and when-not-to-use direction.
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 the readOnlyHint annotation, the description adds behavioral context by specifying the 'active' filter and the exact fields returned (course name, ID, code, term). It doesn't mention pagination or limits, but for a simple list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action verb and resource. Every word contributes meaning, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is complete: it states the scope (active, authenticated user) and the return contents (name, ID, code, term). No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema; the description correctly implies no inputs are needed. The baseline for zero-parameter tools is 4, and no param details are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'courses', and the scope 'all active courses for the authenticated user'. This distinguishes it from sibling list-* tools that target different resources like modules, pages, or assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: lists only active courses belonging to the authenticated user. While it doesn't explicitly name alternatives, no sibling tool offers a comparable course-listing function, making the intended usage unambiguous.
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, and the description reinforces this with 'Does not write to Canvas' and explains the required follow-up call. It also discloses the return value (HTML body plus edit instructions) and optional styleguide inclusion, adding useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short, front-loaded sentences. Each sentence earns its place: core purpose, persistence note with next step, optional styleguide mention, and alternative for full replacement. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains that the tool returns the HTML body alongside edit instructions, making the return value clear. The workflow is complete: fetch and craft instructions, then apply with apply-page-changes. It also covers optional styleguide use and distinguishes from update-page-content, offering full context for a read-only patch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described. The description adds meaning for key parameters: it clarifies 'instructions' are natural-language edit instructions the model applies, and 'includeStyleguide' is an optional inline styleguide for formatting. This goes beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a page's current HTML body and returns it with edit instructions for the model to apply. It explicitly distinguishes itself from update-page-content (full replacement) and apply-page-changes (persistence), making the tool's purpose unique 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the tool does not write to Canvas and instructs to follow up with apply-page-changes to persist, providing a clear when-to-use and next-step. It also names update-page-content as the alternative for full replacement, offering explicit usage guidance.
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:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/r-huijts/canvas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/r-huijts/canvas-mcp)

Score Badge

Copy to your README.md:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/r-huijts/canvas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/r-huijts/canvas-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/r-huijts/canvas-mcp'

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