google-classroom-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct resource and action: accounts, profile, courses, pending assignments, course contents, single assignment, announcements, submission, and reclaim. Even account-related tools differ clearly in purpose: one lists local configuration, the other verifies authentication.
Naming Consistency5/5All tool names follow a consistent lowercase verb_noun pattern (list_, get_, submit_, reclaim_). No mixed conventions or vague verbs appear.
Tool Count5/5Nine tools is well-scoped for a student-facing Google Classroom server, covering viewing, retrieving, submitting, and un-submitting without unnecessary bloat.
Completeness4/5Core student workflows are covered: list courses, see pending work, inspect assignments, view announcements, and submit/reclaim. A minor gap is that there is no aggregate list of all assignments including completed/graded ones across courses; get_course_contents fills this per course but requires a course id.
Average 3.6/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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.jsonto 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?
With no annotations, the description must carry full behavioral burden. It mentions sorting order but omits critical behaviors: pagination (limit parameter), default limits, whether announcements include attachments or metadata, and whether any authentication or permissions are needed. The agent is left without details on what happens with the limit or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that captures the core purpose and ordering. It is appropriately front-loaded with the main action. Omitting details is a trade-off but not verbose, so it earns a 4 for clarity relative to length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description is insufficient. It does not clarify the role of limit and account, nor does it specify the output format (e.g., fields of each announcement). The sorting detail is helpful but not enough for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It does not explain course_id, limit, or account at all, leaving agents to infer from parameter names. Since there is no parameter documentation in the schema, the lack of explanation is a significant gap, though parameter names are somewhat self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly indicates it lists announcements for a course, sorted by most recent to oldest, which defines the core function. However, it does not explicitly distinguish itself from sibling tools like list_courses or list_pending_assignments, but the resource (announcements) is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., requiring a course from list_courses) or when to prefer other tools. Usage is implied for listing announcements but with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool verifies connectivity and returns authenticated user data, and that it can operate per account. However, it does not mention side effects, authentication requirements, error behavior, or what happens when no account is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the core purpose and the parameter behavior without redundancy. Every part of the sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count and simple input schema, the description is minimally viable. It tells the agent what the tool does and how the optional account affects behavior. However, with no output schema and no annotations, the lack of detail about the returned user object and connection-check semantics leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the account parameter. The phrase 'de cada cuenta (o de la indicada)' indicates that the optional account parameter selects a specific account, with the default covering all accounts. This adds meaningful semantic value, though it stops short of explaining accepted formats or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: verify the connection and return the authenticated user for each account (or a specified one). The verb-resource pair is specific and distinct from the sibling tools, though it does not explicitly contrast with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_accounts or get_course_contents. The tool's use case can be inferred, but the description does not state explicit conditions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the action is a mutating withdrawal but does not state potential side effects, irreversibility, permission requirements, or the specific Google restriction it references. The mention of a restriction without details is insufficient 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with two sentences that convey the purpose and a usage condition without redundancy. It is front-loaded with the core action and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is inadequate. It omits parameter explanations, the nature of the Google restriction, and any operational details, leaving the agent with significant gaps that could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the three parameters, including the required coursework_id_or_url. The description does not clarify how account, course_id, or coursework_id_or_url should be used or their meaning beyond what the schema's names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retira/resolves a submitted submission) and its purpose (to allow modification), using a specific verb and resource. It also equates it with 'Anular entrega', making the function unambiguous. Although it references submit_assignment, it still provides a clear purpose distinct from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use only if the user asks ('Úsala solo si el usuario lo pide'), giving a clear condition. However, it relies on a stated restriction 'Misma restricción de Google que submit_assignment' without specifying what that restriction is, leaving the agent to infer or lack critical context about when the tool is valid.
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 no annotations, the description carries the full burden. It discloses that the tool returns current-user delivery status and grades and that it accepts either a course ID or URL, but it does not mention read-only behavior, required permissions, pagination, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the resource scope, the contents returned, and the accepted input format with no filler. 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description gives a reasonable account of return contents and input format. However, it omits any explanation of the account parameter and any caveats about behavior, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that course_id accepts either an ID or a course URL, but it never explains the optional account parameter, leaving part of the input semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns a course's classwork grouped by topic, including assignments with submission status and grade, questions, and materials. This is specific and distinguishes it from siblings like get_assignment or list_announcements, though it does not explicitly name the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of when to call this tool is implied by describing the aggregate course content it returns, but there is no explicit guidance on choosing it over list_pending_assignments, get_assignment, or list_announcements, nor any 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?
No annotations are provided, so the description carries the full burden. It discloses what the tool returns and that it accepts either a full URL or an id/course_id pair. It does not explicitly mention read-only behavior, permissions, error handling, or rate limits, though the 'get' verb implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence delivers the core purpose and expected output; the second gives concrete input format guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the required parameter and the return content well, but omits the account parameter's role and any operational details such as error behavior or prerequisites. For a simple read tool with one required parameter, this is near adequate but still leaves a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the required parameter coursework_id_or_url (full URL or id) and how course_id relates to it, but it says nothing about the account parameter, leaving its purpose and usage ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: retrieving details of a single task or question, and lists the returned fields (instructions, deadline, points, materials, submission status). This distinguishes it from siblings like list_pending_assignments or get_course_contents, which have broader or different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you already have a coursework URL or id plus course_id. However, it does not explicitly state when not to use it or compare it with alternatives such as list_pending_assignments, leaving some routing to inference.
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?
There are no annotations, so the description carries the behavioral load. 'Sin conexión a la API' usefully discloses that this is a local/no-API operation, implying a safe, read-only listing. It does not go into return format or empty-result behavior, but for a simple account list this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short fragments with no filler. The core identity of the tool is front-loaded, and the behavioral note about no API connection adds value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter local listing tool, this is nearly complete: it specifies the returned fields and the key behavior (no API call). It does not mention return format or the possibility of an empty list, but those are minor for this simple use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There are no parameter details needed, and the description correctly focuses on the output instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (configured Google accounts) and the expected output fields (alias and email). It lacks an explicit verb, but combined with the tool name 'list_accounts' the purpose is unambiguous and easily distinguished from the sibling course/assignment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives or when not to use it. The resource is distinct enough from the siblings, but the description does not state any selection conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the conditional turn_in behavior and the 403 failure mode, which is valuable. However, it does not state whether submission is reversible, whether existing attachments are overwritten, or what other side effects occur beyond attaching/submitting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core function, followed by a workflow note and a critical warning. Every sentence adds information and there is no filler, though it is slightly long due to the warning and workflow context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, it explains the key parameters and a likely error, but omits the meaning of course_id and account, and does not describe what a successful response looks like. It is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains drive_ids and links as Drive files/URLs and links, and clarifies turn_in's conditional behavior, but it leaves course_id and account undefined and does not clarify the required coursework_id_or_url beyond its name. The compensation is incomplete for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: attaching Drive files (IDs/URLs) and/or links to an assignment, with conditional submission via turn_in=True. This clearly distinguishes it from read-only siblings like get_assignment and from the opposite action reclaim_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use the tool only when the user asks, and it gives an alternative workflow for local files (upload to Drive via the Google Drive MCP server, then pass the ID). It also warns about a case where the tool should not be used (403 ProjectPermissionDenied) and directs the user to classroom.google.com instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It does disclose the multi-account traversal behavior and the student-enrollment scope. However, it does not mention pagination, output format, permissions, or whether archived courses are handled beyond the include_archived parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short Spanish sentences with no filler or redundant phrases. It is front-loaded with the main purpose and then adds the key account-related nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no annotations or output schema, the description covers the core behavior and account aggregation, but it leaves include_archived and the expected return shape unstated. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains the account parameter (when omitted, it iterates all configured accounts), but it provides no additional semantics for include_archived at all, leaving that parameter to be understood only from its name and schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's resource and scope: Classroom courses in which the user is enrolled as a student. It also distinguishes the tool from siblings such as get_course_contents or get_assignment by emphasizing an aggregate course list rather than a single 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use it (courses where the user is a student) and the behavior when account is not provided (recorre todas las cuentas configuradas). It does not explicitly name alternatives or exclusions, but the context is enough for basic tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It reveals the status filter, grouping, ordering by deadline, and inclusion of overdue indicator. It does not mention pagination, rate limits, or authorization, but for a read-only list tool this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences deliver all essential information—what is listed, statuses included, grouping, sorting, and default scope—without redundantly repeating the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers statuses, grouping, sorting, default behavior, and overdue flag. Since there is no output schema, an agent gets enough to call the tool correctly. Minor missing details (sort direction, pagination, return format) prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions and only shows account/course_id as nullable strings. The description adds crucial semantics: omitting them means scanning all accounts/courses(), which is more than the bare schema provides. It stops short of explaining expected ID formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the exact resource ('pending assignments'), enumerates the included statuses (NEW, CREATED, RECLAIMED_BY_STUDENT), and specifies grouping and sorting. This clearly distinguishes it from siblings like list_courses or get_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the behavior when parameters are omitted ('Sin account ni course_id revisa todos los cursos activos de todas las cuentas'), giving a clear decision rule. It does not explicitly contrast with sibling tools, but the context makes the appropriate use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: