codex_canvas_mcp

by mrchris-ai

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct Canvas resource and action: user info, module listing, generic API read, write policy, and specific create operations for pages, modules, module items, assignments, discussions, and quizzes. The quiz and quiz-question pair are clearly hierarchical, and the generic read tool is distinct from the specific list tool.
Naming Consistency4/5
All tools use the 'canvas_' prefix followed by a verb_noun pattern (get_user, list_modules, create_assignment, etc.). Minor deviations include 'read_api' instead of 'get_api' and 'write_page' instead of 'create_page', but the overall pattern is predictable and consistent.
Tool Count5/5
With 11 tools, the set is well-scoped for a Canvas LMS integration focused on reading course structure and creating content items. Each tool has a clear purpose, and the count falls comfortably in the ideal 3-15 range without feeling bloated.
Completeness3/5
The tool surface covers reading (user, modules, generic API), creation (pages, modules, module items, assignments, discussions, quizzes, quiz questions), and page updates, but lacks explicit update/delete operations for most created entities. The generic canvas_read_api provides a workaround for reads, but delete operations are entirely absent, leaving a noticeable lifecycle gap.
Average 3.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Cannot make changes.' It adds the HTTP method (GET) and scope (one path), but does not disclose other behaviors like error handling, rate limits, or response format. With the annotation covering safety, this is adequate but not 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 sentence, front-loaded with the core purpose, and every word earns its place. 'Read one Canvas REST API v1 path with GET. Cannot make changes.' is maximally concise and structurally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic reader with no output schema, so more context would help, such as mention of arbitrary path coverage or usage hints. The description is adequate for a simple read tool, but it leaves open questions about the query parameter and response shape, making it only a baseline complete.
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 0%, so the description must compensate, but it only mentions 'path' without explaining its format or the optional 'query' object. The schema provides a pattern for path, but the description adds no semantic meaning for either parameter, especially query.
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 reads one Canvas REST API v1 path using GET, which is a specific verb and resource. It also explicitly says 'Cannot make changes,' distinguishing it from write tools. This satisfies the purpose clarity requirement.
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 explains what the tool does but gives no guidance on when to use it versus the specific sibling tools like canvas_get_current_user or canvas_list_modules. It does not mention alternatives or exclusions, so the agent receives no usage 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?
The description adds meaningful behavioral context beyond annotations: it notes the tool is 'disabled by default' and 'requires explicit confirmation,' which are important operational traits not captured by the readOnly/idempotent/destructive hints. It also clarifies the one-at-a-time creation behavior, providing useful 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 front-loaded sentence with no filler or repetition. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the description, the tool has 7 parameters and no output schema, yet the description omits return value behavior and most parameter details. It does not explain what 'approved course' means or how confirmation works, leaving the agent without enough context to invoke it correctly.
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 0%, so the description must compensate, but it only references the 'confirmation' parameter. It does not explain the meaning or constraints of course_id, name, published, description, points_possible, or submission_types, leaving significant semantic 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 clearly states 'Create exactly one Canvas assignment in an approved course,' specifying the verb (create), resource (Canvas assignment), and scope (exactly one, in an approved course). This distinguishes it from sibling creation tools like canvas_create_module or canvas_create_discussion.
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 creating a Canvas assignment and mentions preconditions ('approved course', 'requires explicit confirmation'), but it does not explicitly name alternative tools or state when not to use this tool. The guidance is contextually 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?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the tool is known to be mutating. The description adds valuable context: it is 'disabled by default' and requires 'explicit confirmation', explaining why it might be unavailable. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of fluff. It front-loads the verb and resource, and every word adds meaning. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 3 required, and no output schema, so the description needs to cover return behavior, parameter details, and error states. It provides only minimal context (approved course, confirmation) and omits crucial information like success/failure behavior, response format, and implications of the position/published flags. This is insufficient 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 0%, so the description must compensate for documenting parameters. It only mentions 'explicit confirmation' (mapping to the confirmation parameter) and 'approved course' (vaguely relating to course_id), but does not explain name, position, published, or the format of confirmation. The description fails to provide essential 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 clearly states the tool creates exactly one Canvas module, using a specific verb ('create') and resource ('module'). This distinguishes it from sibling tools like canvas_create_module_item, which creates items within a module. The phrase 'in an approved course' adds scope, 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 mentions prerequisites ('approved course') and a requirement for 'explicit confirmation', which implies the tool is for special cases and not a default action. However, it does not explicitly contrast with alternative tools (e.g., canvas_create_module_item) or state when not to use it. This is clear context 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?
Annotations already indicate a destructive, non-read-only operation. The description adds valuable context beyond annotations by specifying it is 'Disabled by default' and 'requires explicit confirmation', which are crucial behavioral traits. It also mentions the prerequisite of an approved course. This goes beyond simply restating the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and containing no redundant information. It efficiently communicates the key action and the critical confirmation requirement.
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 and no output schema, the description is too brief to be complete. It omits return value expectations, error conditions, or side effects beyond the destructive hint. It does not explain conditional parameter relationships (e.g., external_url vs content_id) or behavior when adding duplicates.
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 0%, so the description must compensate. It hints at the type parameter (content item vs external URL) and emphasizes the confirmation parameter. However, it does not clarify other parameters like position, new_tab, or page_url, leaving many fields semantically unexplained.
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: adding an existing Canvas content item or external URL to a module. It uses a specific verb ('Add') and resource ('module item'), and distinguishes from siblings like canvas_create_module by emphasizing the item already exists.
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 this tool (for existing content items) but does not explicitly state when not to use it or name alternatives. It gives context about needing an approved course and explicit confirmation, but lacks explicit guidance on choosing between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reiterates 'Read-only,' adding little beyond that. It does add the scoping detail 'for one Canvas course,' which implies course_id targets a single course. However, it does not disclose behaviors like pagination, ordering, or what exactly is returned for modules/items. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences immediately state the action and scope, and then note read-only behavior. No filler or redundancy. The information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (one parameter, read-only annotation, no output schema), the description covers the essential purpose, scope, and safety. It tells the agent it will get modules and module items for a single course. It lacks return format or pagination details, but for this level of complexity, the description is largely 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 one required parameter (course_id) with 0% description coverage. The description adds some meaning by stating 'for one Canvas course,' clarifying that course_id identifies the course and that the tool is scoped to a single course. It also indicates the output will include modules and module items. Yet it does not elaborate on parameter format or constraints beyond what the parameter name and schema already imply.
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 'List' with a clear resource ('modules and module items') and scope ('one Canvas course'). This clearly distinguishes it from sibling creation tools like canvas_create_module and canvas_create_module_item, as well as from the more general canvas_read_api.
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 (i.e., when you need to list modules/items for a course), and the 'Read-only' note hints it is safe for inspection. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or contrast with sibling tools. The guidance is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, but the description adds crucial context by stating 'Disabled by default and requires explicit confirmation', which explains the need for a confirmation parameter. The mention of 'approved course' also signals authorization requirements, going beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that conveys the core purpose and key constraints without waste. Every phrase adds value: 'Add one question', 'existing', 'approved course', and 'disabled by default' all contribute essential information.
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 8 parameters (6 required) and no output schema, this description is far too brief to provide adequate context. It fails to explain any parameter semantics beyond confirmation, the behavior of question_type enum, or what happens on success/failure, leaving the agent without sufficient guidance for correct invocation.
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 0%, and the description provides almost no parameter details. It only vaguely references 'explicit confirmation' (mapping to the confirmation parameter) and 'existing Canvas Classic Quiz' (implying quiz_id), but the other six required parameters (course_id, question_name, question_text, question_type, etc.) are left entirely to the schema, which lacks 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 'Add one question to an existing Canvas Classic Quiz in an approved course', specifying the verb (Add), resource (question), and target (existing quiz). This distinguishes it from siblings like canvas_create_classic_quiz, which creates a quiz, and other create_* 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 phrase 'to an existing Canvas Classic Quiz' provides clear context for when to use this tool (for adding questions to quizzes that already exist). It does not explicitly name alternatives or exclusions, but the 'existing' qualifier implies not for creating quizzes, which is handled by a sibling.
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 the tool as non-read-only and destructive, but the description adds that it is 'disabled by default' and 'requires explicit confirmation,' which are important behavioral constraints beyond the schema. This helps the agent understand prerequisites and that the tool will not execute without explicit user confirmation.
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 only two sentences, front-loading the primary purpose and immediately adding a critical constraint. Every word earns its place with no unnecessary detail, making it highly efficient 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?
Given no output schema, the description does not explain return values or error behavior. It also leaves the 'confirmation' parameter value unspecified and does not clarify what 'approved course' means operationally. However, it does disclose the most critical gating (approval and confirmation), making it minimally adequate for a simple creation tool.
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?
The schema has 0% description coverage for all parameters, and the description only adds meaning to the 'confirmation' parameter by indicating it must be explicitly provided. It does not explain expected values for confirmation or clarify the semantics of title, message, course_id, published, or discussion_type, so it fails to compensate 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 'Create exactly one Canvas discussion in an approved course,' identifying the verb (create), resource (discussion), and scope (approved course). This distinguishes it from sibling tools that create modules, assignments, or quizzes.
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 by noting the tool requires an 'approved course' and 'explicit confirmation,' setting prerequisites and conditions for use. However, it does not explicitly mention when to use this tool over alternatives or exclude other creation tools, so it lacks explicit usage comparisons.
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 repeats the readOnlyHint annotation by saying 'Read-only' but adds useful context by specifying 'authenticated user' scope. It does not disclose error handling, rate limits, or response format, which is acceptable given the annotation and simplicity.
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 short sentences with no filler. It states the action and the read-only nature directly and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is sufficient for basic understanding. It doesn't describe the return payload, but the simplicity and annotations compensate. A brief mention of returned fields would make it complete.
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 no parameters, so schema coverage is 100% vacuously. Per the guidelines, a zero-parameter tool gets a baseline of 4, and the description adds no unnecessary parameter information.
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 'Read the authenticated Canvas user's profile' with a specific verb (read) and resource (authenticated user's profile). It distinguishes from sibling write tools like canvas_create_module or canvas_write_page.
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 intended usage is implied by the name and description – if you need the current user's profile, this is the tool. However, no explicit alternatives or exclusions are given, and it doesn't differentiate from canvas_read_api which could also be used for reading.
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 the tool as destructive (destructiveHint=true) and non-read-only. The description adds valuable context beyond this: the restriction to Classic Quizzes, the requirement for an approved course, and the need for explicit confirmation. It does not contradict the annotations and enriches 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 three sentences long, front-loaded with the main purpose, and each sentence adds distinct information (what it does, limitation, requirement). No filler or repetition; it is highly efficient.
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 complexity (6 params, no output schema), the description covers the core behavioral aspects: what is created, the Classic vs New distinction, and the confirmation requirement. It omits specifics about return values or quiz_type nuances, but these are secondary to the main purpose and reasonably supplemented by the schema.
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 coverage is 0%, so the description must compensate for parameter meanings. It only references the 'confirmation' parameter and indirectly references course_id via 'approved course', but leaves title, published, quiz_type, and description without any added context. This is insufficient for a tool with 6 parameters where the schema alone provides limited guidance.
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 exactly one Canvas Classic Quiz'. It specifies the resource type (Canvas Classic Quiz) with the verb 'create', and distinguishes from sibling tools by explicitly stating it is for Classic Quizzes, not New Quizzes, and from quiz_question by focusing on the quiz itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the tool works only in an 'approved course', is for Classic Quizzes (not New Quizzes), and 'requires explicit confirmation'. However, it does not explicitly name alternative tools for other quiz types or when not to use this tool, leaving a small gap.
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, and the description adds value by noting 'Does not expose credentials' and specifying the exact data returned. This goes beyond the annotation, providing safety context about what information is included or excluded.
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, front-loaded with the core function and a useful safety note. Every word earns its place, and there is no redundant or ambiguous wording.
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 no-parameter, read-only getter without an output schema, the description fully covers what the tool does and what it returns. The additional credential-safety note adds helpful context, leaving no meaningful gaps.
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, so the schema fully covers the input structure. Since no parameters exist, the description need not explain parameter semantics; the baseline of 4 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: showing write-policy state and approved course IDs. It uses a specific verb ('Show') and resource ('write-policy state'), distinguishing it from sibling tools that handle users, modules, or page operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or compare with sibling tools like canvas_read_api or canvas_get_current_user, leaving the agent without explicit usage boundaries.
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 significant context beyond the annotations: disabled by default, requires a per-course allowlist, exact user confirmation, and MCP client approval. This goes beyond the simple destructiveHint to explain how the destructive operation is gated and controlled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the purpose first, then constraints, then a clarifying statement. Each sentence conveys essential information with no filler or 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?
The description covers the purpose, scope, and safety prerequisites, which are the most critical aspects for a gated write tool. It does not elaborate on parameter semantics, but the schema provides some names and defaults, and 'exactly one' sets expectation for behavioral scope.
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 17% (only page_url is described). The tool description does not explain the meaning of required parameters like confirmation, body, or course_id, and does not 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 a specific verb and resource: 'Create or update exactly one Canvas page.' It also adds scope ('exactly one') and explicitly distinguishes itself from generic write tools, which helps differentiate it from sibling write tools like canvas_create_module.
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 indicates when to use this tool (for Canvas page creation/update) and explicitly excludes other write actions ('not generic Canvas write access'). It does not name specific alternatives, but the purpose and exclusions are unambiguous.
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:

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

Score Badge

Copy to your README.md:

[![codex_canvas_mcp MCP server](https://glama.ai/mcp/servers/mrchris-ai/codex_canvas_mcp/badges/score.svg)](https://glama.ai/mcp/servers/mrchris-ai/codex_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/mrchris-ai/codex_canvas_mcp'

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