Provides tools for reading and writing Google Classroom data, including courses, topics, coursework, materials, announcements, rosters, submissions, and attachments.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@classroom-mcp-server What assignments are due this week in my classes?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets Claude read and write your Google Classroom data — courses, topics, coursework (assignments), materials (lessons), announcements, rosters, submissions, and all their attachments.
Works with both Claude Code CLI and Claude Desktop (stdio transport).
Read tools
classroom_whoami — show which Google account is currently authorized (confirm it holds your classes)
classroom_list_courses — your classes
classroom_list_topics — topic/section headers in a course
classroom_list_coursework — assignments (with due dates, points, attachments, topic)
classroom_list_materials — posted lesson materials (CourseWorkMaterials)
classroom_list_announcements — stream announcements
classroom_list_roster — students or teachers
classroom_list_submissions — your submissions + grades for an assignment
classroom_dump_course — everything for one course in a single call: topics with their coursework + materials nested, plus announcements, each with attachments
drive_fetch_file_content — read the text content of an attachment by its Drive file id (so the model can actually see what's inside Docs/Sheets/Slides/etc.)
Write tools
classroom_attach_to_submission — attach a Drive file or link to your work
classroom_turn_in_submission — turn in an assignment
classroom_reclaim_submission — unsubmit to edit
classroom_create_topic — (teacher accounts) create a topic
classroom_create_announcement — (teacher accounts) post an announcement
⚠️ Student accounts are read-restricted by Google. You can read all of your own data and submit/reclaim your own work. Creating topics/announcements and seeing other students' submissions require teacher rights on the course — those calls return a clear permission error otherwise.
Note: "subjects" and "lessons" aren't native Classroom objects. Teachers model them with Topics + CourseWorkMaterials, which is what the topic/materials tools surface.
Related MCP server: Canvas LMS MCP Server
Go to Google Cloud Console → create/select a project.
APIs & Services → Library → enable Google Classroom API.
APIs & Services → OAuth consent screen → configure it (External is fine for personal use). Add yourself as a Test user.
APIs & Services → Credentials → Create Credentials → OAuth client ID → application type Desktop app.
Download the JSON.
mkdir -p ~/.config/classroom-mcp
cp ~/Downloads/client_secret_*.json ~/.config/classroom-mcp/credentials.jsoncd classroom-mcp-server
npm install
npm run build
npm run auth # opens a consent URL, catches the redirect, saves token.jsonThe auth script binds a loopback listener on an OS-assigned free port and tells Google to redirect there. Desktop-app OAuth clients may use any port on 127.0.0.1, so there is nothing to configure and no elevated permission needed. The consent screen is bound to a random state value, and a redirect that doesn't carry it back is refused.
token.json holds a refresh token — a standing grant to your Classroom and Drive. It is written 0600, and ~/.config/classroom-mcp/ is kept 0700.
On the consent screen, pick the Google account that actually holds your classes — that's the account the server reads from. To confirm afterwards, run the classroom_whoami tool (just ask Claude "which classroom account am I on?"). To switch accounts, delete the cached token and re-authorize:
rm ~/.config/classroom-mcp/token.json
npm run auth # choose the correct account this timeListing tools return attachments as references (Drive file id, link, etc.). To read what's inside a Drive attachment, take its driveFile.driveFile.id from any coursework/material/dump result and pass it to drive_fetch_file_content. Google Docs come back as plain text, Sheets as CSV, Slides as text; PDFs and images return metadata + a link rather than text. In practice you can just ask Claude "open the attachment on assignment X" and it will chain the calls.
claude mcp add classroom -- node /absolute/path/to/classroom-mcp-server/dist/index.jsEdit claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"classroom": {
"command": "node",
"args": ["/absolute/path/to/classroom-mcp-server/dist/index.js"]
}
}
}Restart Claude Desktop.
Scopes live in src/constants.ts. The defaults request: read of course structure, read/write of your own coursework + topics/announcements, read-only Drive access (drive.readonly, needed so drive_fetch_file_content can open arbitrary Classroom attachments — drive.file wouldn't see files the app didn't create), and userinfo (so classroom_whoami can report the account).
If you change scopes, you must
npm run buildand re-runnpm run authso Google re-issues a token with the new scopes.
To run strictly read-only, replace the write scopes with their .readonly equivalents (e.g. classroom.coursework.me.readonly, drop classroom.topics and classroom.announcements). drive.readonly is already read-only. Then rebuild and re-auth.
Config/token location can be overridden with the CLASSROOM_CONFIG_DIR env var.
Worth understanding before you connect it, because the model drives these tools:
drive_fetch_file_content takes any Drive file id and reads it with your credentials. It is scoped to drive.readonly, which covers your whole Drive — not only Classroom attachments — because Classroom attachments are files the app didn't create and drive.file cannot see them. A file id that reaches the model from somewhere other than your own course listings will still be fetched. Nothing is written to Drive.
Write tools change real state. classroom_turn_in_submission hands work to a teacher; reclaiming it only works while the assignment still allows it. They are annotated readOnlyHint: false so a client can prompt before running them.
Everything runs as one account — whichever you picked at the consent screen. Run classroom_whoami if you're unsure.
For strictly read-only operation, see Scopes.
npm run build # compile to dist/
npm test # unit tests (no credentials or network needed)
npm run typecheck # type-check src + testsThe tests stub the Google clients through setClassroomClient / setDriveClient and drive the tool handlers directly, so the whole suite runs offline.
Symptom | Fix |
| Run |
| Run |
| You're a student calling a teacher-only endpoint, or a scope is missing |
| The redirect didn't come from the consent screen this run opened. Nothing was saved — run |
Attach a Drive file or link to a student submission BEFORE turning it in. Add attachments first, then call classroom_turn_in_submission.
Args:
course_id, coursework_id, submission_id (strings)
drive_file_id (string, optional): Drive file to attach
link_url (string, optional): URL to attach (provide exactly one)
Returns: Confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the mutating nature, the required before-turn-in state, the one-of constraint, and the return confirmation. This goes beyond the annotations, which already indicate a non-read-only, non-idempotent, non-destructive operation; no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most important guidance ('BEFORE turning it in'), followed by a clear argument list and return note. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no schema-declared parameters and no output schema, the description covers all necessary invocation details: required IDs, optional attachment selection, the one-of requirement, sequencing, and the return confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema is empty, the description manually documents all five parameters with types, optionality, and the exactly-one constraint. This fully compensates for the missing schema information and directly guides the agent on what to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Attach a Drive file or link to a student submission'. It also distinguishes itself from the sibling classroom_turn_in_submission by emphasizing the BEFORE turning it in ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to add attachments first and then call classroom_turn_in_submission, giving clear sequencing and naming the sibling alternative. It also clarifies that exactly one of drive_file_id or link_url must be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post an announcement to a course stream. Requires teacher rights.
Args:
course_id (string), text (string, 1-10000 chars)
Returns: The new announcement's id.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Announcement body text | |
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish non-read-only, non-idempotent, non-destructive behavior. The description adds the authorization requirement and the return value ('The new announcement's id'), which are behavioral details beyond the annotations. It does not describe side effects like notifications, but the annotation set lowers that burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, tightly packed components: action+prerequisite, args, and return. It is front-loaded and contains no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the action, authorization requirement, arguments, and return ID, which is nearly everything needed. The only notable gap is that course_id is not explicitly tied to classroom_list_courses, but that is inferable from the sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section merely restates the schema's types and length bounds, adding no new meaning. With schema description coverage at 50%, the description needed to clarify what course_id refers to or how to obtain it, but it does not. The text parameter gains no value beyond the schema's existing description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Post an announcement to a course stream.' This clearly distinguishes the tool from sibling list/read tools and from classroom_create_topic. The teacher-rights qualifier further pins down intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a meaningful precondition ('Requires teacher rights'), giving the agent clear context for when invocation is appropriate. It does not explicitly name alternatives or when-not conditions, but the action is specific enough that confusion with read-only sibling tools is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new topic in a course. Requires teacher rights on the course; will fail with a permission error for student accounts.
Args:
course_id (string), name (string, 1-100 chars)
Returns: The new topic's id and name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Topic name | |
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses an important precondition (teacher rights) and a failure mode (permission error for students). It also states that the call returns the new topic's id and name. This adds useful behavioral context beyond readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized: purpose, permission note, args, and return value. Each sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create operation, the description covers the essential context: required permissions, failure mode, and return shape. Since there is no output schema, providing the return value is important and is handled correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter section restates the schema's types and constraints: course_id as string and name as string with 1-100 chars. Since schema coverage is only 50% and course_id has no description in the schema, the description adds marginal value by listing it, but it does not explain what course_id refers to or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a new topic in a course.' It names the target (topic), the scope (course), and the role (teacher), clearly separating it from sibling tools like classroom_create_announcement or classroom_list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by stating that teacher rights are required and that student accounts will receive a permission error. It does not explicitly name alternatives or say 'use this instead of X,' but the resource-specific language makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a course's full structure in one call: every topic with its coursework and materials nested underneath, anything without a topic grouped separately, and optionally the announcement stream. Each item includes its attachments. This is the fastest way to get a complete picture of a class.
Args:
course_id (string): Course ID
include_announcements (boolean): default true
max_per_type (number): per-category cap 1-500 (default 200)
response_format ('markdown' | 'json')
Returns: { course, topics: [{ id, name, coursework[], materials[] }], no_topic: { coursework[], materials[] }, announcements[] }. To read the text of any attachment, pass its driveFile.driveFile.id to drive_fetch_file_content. Very large dumps truncate descriptions; use the per-resource tools for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | Course ID from classroom_list_courses | |
| max_per_type | No | Cap on items fetched per category | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
| include_announcements | No | Include the announcement stream (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the description focuses on additional behavioral traits: nested grouping, per-category caps, optional announcements, and truncation of descriptions in large dumps. This adds meaningful context beyond the annotated safety profile, though it could be more explicit about what happens when a category exceeds the cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose sentence, a compact Args list, and a valuable Returns paragraph. The Args section duplicates schema details and could be trimmed, but the overall length is justified by the useful behavioral and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description fully specifies the return shape, including nested topics, no_topic grouping, and announcements. It also covers truncation behavior and attachment handling. Minor gaps remain around error conditions and pagination beyond the cap, but the description is largely complete for this read-only aggregation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters, including defaults, ranges, and enums. The description's Args section repeats this information almost verbatim without adding new semantics, so it earns the baseline 3 for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool fetches a course's full structure in one call, with topics, coursework, materials, and optional announcements nested. It distinguishes itself from the per-resource sibling tools by being 'the fastest way to get a complete picture of a class.' No ambiguity remains about what resource is operated on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this as the go-to for a full course snapshot and directs users to per-resource tools when full detail is needed due to truncation. It also tells users how to read attachment text via drive_fetch_file_content, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List announcements posted to a course stream, including any attachments.
Args:
course_id (string): Course ID
limit (number): Max items 1-200 (default 30)
response_format ('markdown' | 'json')
Returns: Each announcement's id, text, state, creationTime, updateTime, alternateLink, and materials.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| course_id | Yes | Course ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds useful context by stating that attachments are included and by enumerating the exact returned fields, which goes beyond the annotations and helps the agent understand the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action and uses a clear Args/Returns structure, making it easy to scan. The Args section is somewhat redundant with the input schema, but the overall length is appropriate and there is no unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter and simple optional parameters, and the description covers the course scope, limit behavior, response format, and the complete set of returned fields. With no output schema present, the explicit Returns list is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description lists all three parameters but mostly restates the schema. It repeats course_id as 'Course ID', limit's default/range, and response_format's enum/meaning, adding no deeper semantics beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List announcements posted to a course stream, including any attachments,' which clearly names the verb, resource, and scope. It is distinct from sibling tools by resource type, but it does not explicitly differentiate itself from tools like classroom_list_coursework or classroom_list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when you need announcements from a course stream, especially with attachments. However, there is no explicit when-to-use or when-not-to-use guidance and no mention of alternative sibling list tools, so the agent must infer selection from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Google Classroom courses (classes) the authenticated user is enrolled in or teaches.
Args:
course_states (string[]): Filter by state, default ["ACTIVE"]
limit (number): Max courses, 1-200 (default 50)
response_format ('markdown' | 'json'): default 'markdown'
Returns: Each course's id, name, section, description heading, room, ownerId, enrollmentCode, and courseState. Use the returned course id with the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max courses to return | |
| course_states | No | Which course states to include (default: ACTIVE only) | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations by specifying return fields, default state filtering, and how the returned course ids connect to other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with a one-sentence purpose, an Args list, and a Returns note. Every sentence earns its place, and the most decision-relevant information—what the tool lists and what to do with the output—is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description fully explains the return values and includes the important integration instruction to use returned course ids with other tools. Combined with complete parameter schemas and strong annotations, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 repeats the parameter meanings and defaults but does not add significant meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('Google Classroom courses'), and a scope ('the authenticated user is enrolled in or teaches'). This clearly distinguishes it from sibling list tools such as classroom_list_topics and classroom_list_coursework.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is the entry point for listing courses, and it explicitly tells the agent to use the returned course id with other tools. It does not explicitly name alternatives or state when not to use this tool, but the resource scope makes the usage situation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List coursework (assignments, questions) in a course, including attached materials, due dates, point values, and the topic each belongs to.
Args:
course_id (string): Course ID
topic_id (string, optional): Restrict to one topic
limit (number): Max items 1-200 (default 50)
response_format ('markdown' | 'json')
Returns: Each item's id, title, description, workType, state, dueDate, maxPoints, topicId, alternateLink, and materials (attachments).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic_id | No | Optional: filter to a single topic (client-side filter) | |
| course_id | Yes | Course ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context by outlining exactly what is returned, including materials, due dates, points, and topic associations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then follows a clean Args/Returns structure. Every sentence carries useful information, with no fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the Returns section does a good job enumerating the important fields. It could be slightly more complete by clarifying how response_format changes the output or by noting edge cases, but the core calling context is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description restates all four parameters with brief meanings. It adds some value for the 'limit' parameter (which the schema lacks a description for) and clarifies 'topic_id' as a restriction, but it does not go deeper with examples or parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('coursework (assignments, questions)') scoped to a course, and enumerates the key returned attributes. However, it does not explicitly distinguish itself from sibling tools like classroom_list_materials or classroom_list_submissions, which could overlap in an agent's mind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this to list assignments/questions in a course, optionally filtered by topic. But there is no explicit guidance about when not to use it or which sibling tool to prefer for materials-only or submission-only needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CourseWorkMaterials — posted reading/lesson materials that are NOT assignments. These are what teachers typically use for lessons and resources.
Args:
course_id (string): Course ID
topic_id (string, optional): Restrict to one topic
limit (number): Max items 1-200 (default 50)
response_format ('markdown' | 'json')
Returns: Each material's id, title, description, state, topicId, alternateLink, and its attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic_id | No | Optional topic filter | |
| course_id | Yes | Course ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful semantic scope by clarifying it returns CourseWorkMaterials rather than assignments, but it does not disclose additional operational behavior such as pagination behavior, auth requirements, or list completeness. It is not contradicted by any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core distinction is front-loaded in a single, clear sentence. The Args and Returns sections are compact and scannable, and every part earns its place. There is mild duplication with the input schema, but no filler or unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description appropriately lists the returned fields in the Returns section. It covers all parameters, the output format options, and the material type scope. Minor gaps remain around pagination behavior and any auth or error conditions, but the annotations already cover the read-only and idempotent nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description mostly restates what the schema already provides. It adds minor clarification with 'Restrict to one topic' for topic_id and fills in the missing schema description for limit with 'Max items 1-200 (default 50)', but most parameter meaning is already present in the schema. This adds some value but does not go beyond a baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List CourseWorkMaterials'. It clearly distinguishes these from assignments, which immediately separates this tool from sibling tools like classroom_list_coursework. The phrase 'posted reading/lesson materials' and 'what teachers typically use for lessons and resources' removes any ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance by stating these are materials that are NOT assignments, which tells an agent not to use this tool when the goal is assignments. It does not explicitly name sibling alternatives such as classroom_list_coursework or classroom_list_announcements, so it falls just short of full explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List students or teachers enrolled in a course.
Args:
course_id (string): Course ID
role ('students' | 'teachers'): default 'students'
limit (number): Max 1-200 (default 100)
response_format ('markdown' | 'json')
Returns: Each person's userId and profile name/email (email only if your scope and the domain permit it).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Which roster to fetch | students |
| limit | No | ||
| course_id | Yes | Course ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying the return fields and the caveat that email visibility depends on scope and domain permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, an Args list, and a Returns line. There is no fluff, though the Args block partially duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the Returns line is valuable and explains what the agent will receive. It covers role, limit, response format, and email visibility caveats. It omits pagination or error behavior, but for this simple read-only roster tool, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section largely restates what the input schema already provides. It does add a human-readable constraint for limit ('Max 1-200 (default 100)'), which the schema only expressed via min/max/default values, but it does not deeply enrich course_id or response_format beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List students or teachers enrolled in a course,' which is a specific verb and resource. This clearly distinguishes it from sibling list tools such as classroom_list_courses, classroom_list_coursework, and classroom_list_announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: fetching roster members for a course. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous enough that an agent can route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List student submissions for a specific assignment. As a student you'll see your own submission(s); as a teacher you'll see all.
Args:
course_id (string): Course ID
coursework_id (string): The assignment's id
response_format ('markdown' | 'json')
Returns: Each submission's id, userId, state (NEW/CREATED/TURNED_IN/RETURNED/RECLAIMED), late flag, assignedGrade, draftGrade, and attachments. Use the submission id with the turn-in / attachment write tools.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | Course ID | |
| coursework_id | Yes | CourseWork (assignment) ID | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety and idempotency, so the description does not need to repeat that. It adds genuine behavioral context: role-dependent visibility, the submission state enum, late/grade fields, attachments, and the connection to write tools. This goes well beyond the structured 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized: purpose first, then arguments, then returns. The only mild redundancy is that the Args list repeats schema properties, but the overall text is short, scannable, and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description supplies the essential usage context: role-based behavior, returned fields, and how to use the submission id afterward. All parameters are covered by the schema, and safety is covered by annotations, so nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents course_id, coursework_id, and response_format, including defaults and enum values. The Args section in the description largely mirrors the schema rather than adding new parameter-level meaning, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource: 'List student submissions for a specific assignment.' This clearly distinguishes the tool from sibling list tools like classroom_list_courses, classroom_list_topics, and classroom_list_coursework. The role-based visibility note ('student... own; teacher... all') further pins down exactly what the tool does and what results to expect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it: with a course_id and coursework_id to list submissions for a particular assignment. It also points the agent to related write tools by noting the submission id is used with turn-in/attachment tools, which helps with subsequent tool selection. It does not explicitly name an alternative list tool or provide a when-not-to-use condition, but among the siblings this is the only submission-list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all topics (the section headers teachers use to group work) within a course. Teachers often use topics to represent units, subjects, or lessons.
Args:
course_id (string): Course ID
response_format ('markdown' | 'json')
Returns: Each topic's topicId and name. Pass topicId to classroom_list_coursework to filter materials/assignments by topic.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | Course ID from classroom_list_courses | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, open-world, and non-destructive. The description adds useful context about what is returned and how topics are used, but it does not disclose additional behavioral traits such as pagination, ordering, or potential error cases. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The extra sentences about what topics represent and how to use topic IDs add value without excessive length, though the Args block duplicates schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the return content (topicId and name), the relationship to sibling tool classroom_list_coursework, and the role of the main parameter. The annotations cover safety, so no critical behavioral information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: course_id and response_format are both documented with types, defaults, and source guidance. The description's Args section mostly restates schema information, so it adds little beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all topics ... within a course.' It also clarifies what topics are in the teacher/classroom context, making the tool's purpose unambiguous and distinguishable from sibling listing tools like classroom_list_coursework or classroom_list_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when this tool is useful: to obtain topic IDs for a course, and then pass each topicId to classroom_list_coursework. It provides actionable usage context but does not explicitly state when not to use it or compare it against alternatives like classroom_list_announcements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reclaim a turned-in submission (pull it back to make edits), equivalent to "Unsubmit". Only works if the assignment still allows it and state is TURNED_IN.
Args:
course_id, coursework_id, submission_id (strings)
Returns: Confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| coursework_id | Yes | ||
| submission_id | Yes | From classroom_list_submissions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, and the description adds useful behavioral context: the operation is equivalent to Unsubmit, works only in TURNED_IN state, and returns a confirmation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the action and equivalence appear first, followed by necessary preconditions and a brief Args/Returns structure. Every sentence adds information; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action, precondition, and return type are covered, which is adequate for a simple three-string-parameter tool. However, it does not explain where course_id and coursework_id come from, nor the side effects on the submission beyond 'make edits'. These are notable gaps given no output schema and sparse parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%; only submission_id has a description ('From classroom_list_submissions'). The description's Args section merely lists names and says they are strings, adding no meaning for course_id or coursework_id. Given the low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reclaim a turned-in submission (pull it back to make edits)', with a well-understood equivalent, 'Unsubmit'. It distinguishes the tool from its opposite sibling classroom_turn_in_submission without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit preconditions: 'Only works if the assignment still allows it and state is TURNED_IN.' This is clear context and even a when-not condition, though it does not explicitly name alternative tools for different submission states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn in (submit) a student assignment submission. This hands the work to the teacher and is the equivalent of clicking "Turn in". State must currently be CREATED or NEW.
Args:
course_id, coursework_id, submission_id (strings)
Returns: Confirmation. NOTE: This changes submission state and is not trivially reversible (use classroom_reclaim_submission to pull it back if still allowed).
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| coursework_id | Yes | ||
| submission_id | Yes | From classroom_list_submissions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the tool mutates submission state, is not trivially reversible, and names the reclaim tool for undoing it. This adds meaningful context beyond the annotations, which only indicate readOnlyHint=false and idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core purpose, then adds state requirements, return info, and reversal guidance in a structured way. The Args list is somewhat redundant with the schema, but the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the critical state precondition, the mutation behavior, and the reversal path, which are essential for correct use. Missing details like error behavior for invalid states or fuller parameter semantics leave minor gaps, but the tool is otherwise well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only submission_id having a description. The description merely lists param names and types but does not explain course_id or coursework_id beyond what the schema already shows, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: turning in/submitting a student assignment submission, with the concrete analogy of clicking 'Turn in'. It names the required state (CREATED or NEW) and is distinct from sibling tools like listing or reclaiming submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: to submit work to the teacher, and only when state is CREATED or NEW. It also explicitly points to the reclaim sibling for reversing the action if allowed, giving useful guidance for choosing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which Google account this server is currently authorized as. Use this to confirm the server is pointed at the Google login that actually holds your classes. If it's the wrong account, delete the cached token (token.json) and run npm run auth again, choosing the correct account on the consent screen.
Args:
response_format ('markdown' | 'json')
Returns: the authorized account's email, name, and id.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by emphasizing that this is a read-only check of the 'currently authorized' account and implying that fixing an incorrect account requires external steps like deleting token.json and re-running npm run auth rather than changing state through this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a concise use case, a practical troubleshooting note, the argument list, and the return value description. Every sentence earns its place, and nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 optional parameter and no output schema, the description is fully sufficient. It states what the tool returns (email, name, id), how to invoke it, and how to interpret the response_format parameter, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter, response_format, and the input schema already fully documents it with an enum, a default, and a description. The description's Args section repeats that information without adding meaningful semantic detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show which Google account this server is currently authorized as.' It clearly differentiates this tool from the classroom_* siblings, which all operate on Google Classroom data rather than on the authorization identity itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use this to confirm the server is pointed at the Google login that actually holds your classes.' It also provides actionable remediation for the wrong-account case, though it does not discuss when not to use it or name alternatives because no real sibling alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the text content of a Google Drive file attached to Classroom coursework, materials, or announcements.
Handles each type appropriately:
Google Docs → exported as plain text
Google Sheets → exported as CSV
Google Slides → exported as plain text
text/csv/markdown/html/json/xml/rtf → downloaded directly
PDFs, images, and other binary files → returns metadata + link (content can't be rendered as text)
Args:
drive_file_id (string): The Drive file id from an attachment's driveFile.driveFile.id
response_format ('markdown' | 'json')
Returns: name, mime_type, size, link, and (when readable) content. Long content is truncated to a character limit with a note.
Error Handling:
403/permission → the Drive scope may be missing; re-run npm run auth
404 → the file id is wrong or you lack access to that file
| Name | Required | Description | Default |
|---|---|---|---|
| drive_file_id | Yes | The Drive file id of an attachment. Find it in the materials arrays returned by classroom_list_coursework / list_materials / dump_course (driveFile.driveFile.id). | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for raw data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavior beyond the annotations: per-file-type export behavior, binary-file fallback to metadata and link, truncation with a note, and specific error handling for 403 and 404. Annotations already mark the tool read-only and idempotent, and the description adds valuable operational context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with a clear lead sentence followed by concise bullets for file-type handling, arguments, return value, and errors. Every section serves an operational purpose and the most important behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description sufficiently explains what will be returned, how different file types are treated, what happens with binary files, and how to handle common errors. Combined with the annotations and complete input schema, an agent has everything needed to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 repeats the parameter names and enum values already present in the schema and adds only minor clarification about where drive_file_id comes from. It does not substantially extend the schema's parameter explanations, but it does not need to given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read the text content') applied to a specific resource ('Google Drive file attached to Classroom coursework, materials, or announcements'). It clearly differentiates the tool from the sibling classroom_* tools, which primarily list or manage Classroom data rather than fetch and interpret attachment file contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you have a Drive file id from a Classroom attachment and need its readable text content. It does not explicitly name sibling alternatives or state when not to use the tool, but the unique purpose and detailed handling instructions make 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0classroom_attach_to_submissionclassroom_create_announcementclassroom_create_topicclassroom_dump_courseclassroom_list_announcementsclassroom_list_coursesclassroom_list_courseworkclassroom_list_materialsclassroom_list_rosterclassroom_list_submissionsclassroom_list_topicsclassroom_reclaim_submissionclassroom_turn_in_submissionclassroom_whoamidrive_fetch_file_contentEach list_* tool targets a distinct Classroom resource (courses, topics, coursework, materials, announcements, roster, submissions), and coursework/materials/announcements are explicitly differentiated. Action tools like turn_in, reclaim, and attach have clear, non-overlapping state-transition roles.
The set consistently uses a classroom_verb_noun pattern for nearly all tools, with predictable verbs like list, create, turn_in, reclaim, and attach. Minor exceptions are drive_fetch_file_content (different namespace) and classroom_whoami (not verb_noun), but both are still clear and intentional.
Fifteen tools is at the upper end of the ideal range but every tool earns its place: granular listers, a course dump convenience, submission actions, two create operations, a Drive helper, and an auth-check tool. There is no meaningful redundancy in the set.
The read-side is strong and the student submission lifecycle is well covered. However, the authoring/management surface is incomplete: there is no way to create coursework or materials, update/delete existing announcements, topics, or coursework, or grade/return submissions as a teacher.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give Claude only the Google Drive files you choose. Every action logged.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
AI-powered corporate learning platform — manage courses, users, and insights via Claude.
Personal CRM for Claude. Contacts live as plain-text files in your own Google Drive.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ymr-gif/classroom-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
