Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/educator. Endpoint unchanged: https://mcp.moltlinestudio.com/educator — still live, still free on the free tier. Only this duplicate entry is deprecated.
8 teaching persona and skill products plus computed classroom tools over MCP: readability_report runs a real Flesch-Kincaid analysis with leveling suggestions, grade_curve turns score lists into full distribution statistics, lesson_timer splits class periods, and get_free_skill loads any product's complete free gateway skill.
Load a product's free gateway skill with its complete instructions. FREE.
Typical input {"slug": "curriculum-architect-hs"} returns {"slug": ..., "skill": "", "instructions": ""}.
Returns exactly one skill - the product's free gateway skill - chosen automatically from the slug, with no plan required. Use when the caller wants usable instructions immediately. Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''. Use list_products."}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "curriculum-architect-hs"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that the tool never raises a protocol error, returns a structured error object with troubleshooting advice, and confirms that every call is read-only and idempotent, making retries safe. This is significant behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and well-structured: purpose first, then example, usage scope, error behavior, and idempotency. Every sentence adds value and there is no 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?
Given the tool's simplicity (single parameter, output schema present), the description covers all necessary aspects: purpose, input, output example, error handling, usage context, and idempotency. It is fully self-contained and requires no further clarification.
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 already has 100% description coverage for the 'slug' parameter, including the example and source. The description repeats this information (e.g., 'Product slug exactly as returned by list_products') and adds a sample output, but does not introduce new semantic meaning beyond what the schema provides. Baseline is 3.
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 verb 'Load' and the resource 'product's free gateway skill with its complete instructions'. It provides a typical input/output example and explicitly distinguishes this tool from the sibling 'get_full_skill', which is for other skills and requires a paid plan.
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 says 'Use when the caller wants usable instructions immediately' and explicitly states what it is not for: 'Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan.' This provides 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.
Load one product in full: its persona plus every paid skill. PREMIUM (license).
Typical input {"slug": "curriculum-architect-hs"} returns {"slug": ..., "name": ..., "persona": "", "skills": [{"name": ..., "instructions": ...}, ...], "free_skill": {...}}.
Returns persona plus every skill for one product. Use when the caller wants the whole product. Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "curriculum-architect-hs"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description goes beyond by explicitly stating 'Every call is read-only and idempotent' and detailing the error handling behavior: 'never raises a protocol error — it returns {"error": ...}' with examples. This adds significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. It includes an example, usage guidance, error details, and essential behavioral notes. Every sentence contributes value; slight redundancy in restating the purpose could be trimmed, but overall it is appropriate for the information density.
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 the tool has only one parameter and an output schema exists (as indicated by context signals), the description covers all necessary aspects: purpose, example, usage against siblings, error behavior, and idempotency. It is fully complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for slug. The description adds a typical input example and specifies that the slug must be exactly as returned by list_products, which provides context beyond the schema. While schema already covers minLength and description, the added example and source reference earn a score above baseline 3.
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 tool loads one product in full including persona and every paid skill. It provides a typical input/output example and explicitly distinguishes from sibling tools like get_full_skill and get_free_skill, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the caller wants the whole product' and provides clear exclusion criteria: 'Not for a single skill (get_full_skill) and not for a free look, which list_products and get_free_skill provide with no plan.' It also mentions retry safety after error correction, offering comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load one paid skill's complete instructions from a product. PREMIUM (license).
Typical input {"slug": "curriculum-architect-hs", "skill_name": "unit-planner"} returns {"slug": ..., "skill": ..., "instructions": ""}.
Returns one named skill, selected by skill_name. Use when the caller wants one specific paid skill. Not for the free gateway skill, which get_free_skill returns with no plan, and not for every skill at once (get_full_product). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "unknown slug ''"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug exactly as returned by list_products, e.g. "curriculum-architect-hs"; must be non-empty. | |
| skill_name | Yes | Exact skill name as listed in that product's "skills" array from list_products, e.g. "unit-planner"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which already note readOnly, idempotent, non-destructive), the description adds critical behavioral details: error handling (returns error JSON, never a protocol error), retry safety, and a concrete example of the return shape. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, provides a concrete example immediately, and every sentence earns its place. Spans 7 sentences but each adds distinct value—purpose, example, selection, exclusions, error handling, safety.
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 an output schema present, the description need not detail return values, and it still covers purpose, usage guidance, error behavior, and idempotency. The description is complete for a focused lookup tool with robust annotations and schema.
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% with strong descriptions for both parameters, so baseline is 3. The description adds value by explaining the typical input/output JSON format and connecting the parameter values to list_products output, elevating it above the baseline.
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 verb ('Load'), resource ('one paid skill's complete instructions from a product'), and scope, explicitly distinguishing from siblings like 'get_free_skill' and 'get_full_product'.
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 says when to use ('when the caller wants one specific paid skill'), when not to use ('Not for the free gateway skill... not for every skill at once'), and names alternative tools ('get_free_skill', 'get_full_product').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize how an assessment landed: stats, bands, and outliers. FREE.
Reports mean, median, std dev, quartiles, distribution by percentage band, and flagged low outliers. Typical input {"scores": [88, 92, 75, 61, 84], "max_score": 100} returns {"n": 5, "mean": 80.0, "median": 84.0, "std_dev": ..., "q1": ..., "q3": ..., "distribution": {"90-100%": 1, ...}, "outliers_low": [...], "reading": "..."}.
Use on a list of scores already earned. Not for the readability of the assessment itself (readability_report). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "no scores"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| scores | Yes | Raw scores, one per student; at least 1 value, e.g. [88, 92, 75]. | |
| max_score | No | Maximum possible score; must be greater than 0. Default 100. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds significant behavioral detail: 'this tool never raises a protocol error — it returns {"error": "..."}' and 'Every call is read-only and idempotent.' This enriches the agent's understanding of error handling and retry behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, output summary, example, sibling distinction, and error handling. It is slightly verbose (e.g., the example output is lengthy), but every sentence contributes value. No redundancy or fluff.
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 the tool only has 2 parameters, the description fully covers purpose, input, output (including sample and error case), and compares to siblings. The presence of an output schema (implied by the sample) means the description does not need to explain return values in detail, but it does so anyway. The description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds meaning by providing a concrete example of typical input and output, clarifying the expected format and what the tool returns. It also explains the default value for max_score and the requirement for minItems:1 in scores.
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 tool's purpose: 'Summarize how an assessment landed: stats, bands, and outliers.' It specifies the verb (summarize/generate stats), the resource (assessment scores), and differentiates from the sibling tool readability_report by explicitly stating 'Not for the readability of the assessment itself.' The provided input/output example further solidifies the 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 explicit usage guidance: 'Use on a list of scores already earned. Not for the readability of the assessment itself (readability_report).' It also advises on error handling and retry safety: 'after correcting the input it is always safe to retry.' This clearly tells when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a class period into timed segments with sensible weighting. FREE.
The opener and closer get less time; core activities get more. Typical input {"minutes": 50, "segments": ["Warm-up", "Direct instruction", "Practice", "Exit ticket"]} returns {"period_minutes": 50, "plan": [{"segment": "Warm-up", "start_min": 0, "duration_min": 8}, ...], "note": "..."}.
Use when one fixed class period must be divided into segments. Not for multi-day planning and not for spaced review, which the personal server's spaced_repetition_plan builds. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "need segments and at least 5 minutes"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | Yes | Length of the class period in minutes; at least 5, e.g. 50. | |
| segments | Yes | Ordered segment names, e.g. ["Warm-up", "Practice", "Exit ticket"]; at least 1 entry. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing error behavior: 'on invalid, missing, or malformed input this tool never raises a protocol error — it returns an error object' and reiterates the idempotent, read-only nature. This is fully consistent with annotations (readOnlyHint, idempotentHint, destructiveHint) with no contradictions.
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 purpose, followed by a clear example, usage guidelines, error handling, and safety note. Every sentence adds distinct value. It is appropriately sized for the tool's simplicity and well-structured for an agent to parse quickly.
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 the tool's low complexity (2 parameters, output schema exists), the description covers all essential aspects: purpose, input format, algorithm, error handling, safety guarantees, and usage boundaries. The example of the output structure compensates for not needing to elaborate on the output schema.
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% with descriptions for both parameters. The description adds a concrete input example (minutes: 50, segments list) and explains the weighting logic ('opener and closer get less time; core activities get more'). This provides context beyond the schema's parameter 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 states 'Split a class period into timed segments with sensible weighting', which is a specific verb and resource. It clearly distinguishes the tool from unrelated sibling tools like get_free_skill or readability_report. The example further reinforces the 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?
Explicit guidance is provided: 'Use when one fixed class period must be divided into segments. Not for multi-day planning and not for spaced review, which the personal server's spaced_repetition_plan builds.' This tells the agent exactly when and when not to use the tool, and names an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 8 educator products with their included skills. FREE.
Takes no arguments. Typical input {} returns a list of 8 product objects, each {"slug": "curriculum-architect-hs", "name": ..., "tagline": ..., "skills": ["Skill A", ...], "free_skill": "Gateway Skill Name"}. Use the returned slug values with get_free_skill, get_full_product, or get_full_skill.
Returns metadata only - no persona text and no skill instructions. Use when the caller wants to see what this server covers. Not for keyword search across the whole 138-product catalog, which the catalog server's search_catalog does, and not for instructions the caller can act on (get_free_skill). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that errors are returned as objects with fix instructions, no protocol errors. Also specifies that only metadata is returned, no persona text or skill instructions.
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?
Description is appropriately sized, front-loaded with purpose, then covers arguments, return format, usage, alternatives, and error handling. Every sentence is informative with no 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?
Given the tool's simplicity (no parameters, output schema exists), the description fully covers what the tool returns (product objects with specific keys), error format, and usage context. No gaps identified.
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?
With 0 parameters, schema coverage is 100%. The description adds value by stating 'Takes no arguments' and showing typical input '{}', which is clear and helpful beyond the empty schema.
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 tool lists the 8 educator products with their included skills, using specific verb and resource. It distinguishes from siblings by explaining how to use the returned slugs with other tools and contrasting with search_catalog and get_free_skill.
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?
Explicitly states when to use ('when the caller wants to see what this server covers') and when not to use ('not for keyword search...not for instructions'). Names alternative tools (search_catalog, get_free_skill) for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze teaching text with Flesch-Kincaid readability and leveling advice. FREE.
Typical input {"text": "", "target_grade": 6} returns {"flesch_kincaid_grade": 8.2, "reading_ease": 62.1, "sentences": N, "words": N, "avg_words_per_sentence": N, "long_sentences_over_25w": N, "polysyllabic_words_sample": [...], "target_grade": 6, "gap": 2.2, "suggestions": ["..."]}.
Use on teaching text where the reading level matters. Not for scores students earned (grade_curve) and not for general prose style, which the creator server's analyze_writing covers. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "empty text"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The passage to analyze — at least one full sentence of plain text; must be non-empty. | |
| target_grade | No | Target grade level 1-12; when set, the report adds a gap assessment against it. 0 (default) skips it. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds error behavior: never raises protocol error, returns error object with fix info. It also confirms idempotency and retry safety. 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 somewhat long but well-structured: purpose first, then example, usage guidance, error handling, idempotency. Every sentence adds value, though it could be slightly more concise.
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 the tool's complexity (2 parameters, output schema available, annotations present), the description covers purpose, usage, error behavior, idempotency, and business context (FREE). It is fully adequate for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value with an example input/output showing how target_grade=6 affects the response, clarifying the gap assessment. This exceeds mere schema repetition.
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 tool analyzes teaching text with Flesch-Kincaid readability and leveling advice. It distinguishes from siblings by explicitly stating it is not for scores students earned (grade_curve) and not for general prose style (covered by analyze_writing).
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 explicit when-to-use ('Use on teaching text where the reading level matters') and when-not-to-use ('Not for scores students earned (grade_curve) and not for general prose style'), naming specific alternatives.
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.
get_free_skillget_full_productget_full_skillgrade_curvelesson_timerlist_productsreadability_reportClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
All seven tools have clearly distinct purposes. The three product/skill retrieval tools (get_free_skill, get_full_skill, get_full_product) are precisely differentiated by what they return. The remaining four tools (list_products, grade_curve, lesson_timer, readability_report) each target a unique function with no overlap.
Tool names use a mix of verb_noun (get_free_skill, get_full_skill, list_products) and noun_noun (grade_curve, lesson_timer, readability_report) patterns. While each name is readable and the convention is not chaotic, the lack of a uniform pattern reduces consistency.
Seven tools is a well-scoped count for an educator toolkit. Each tool addresses a distinct need: product discovery, skill retrieval, assessment analysis, lesson planning, and readability checking. No tool is superfluous, and the number feels complete without being overwhelming.
The tool surface covers the core domain: product listing, skill retrieval (free and paid), assessment statistics, lesson timing, and readability analysis. Minor gaps exist, such as the absence of a search or comparison feature across products, but the essential workflows are supported without dead ends.