Text generation over MCP: prose, emails, blog outlines, SQL, humanizing, text diffs, fake data.
Each tool maps to a distinct output or transformation—comparing, email drafting, outlining, fake person data, SQL, filler prose, and humanizing—and the descriptions explicitly route overlapping cases (e.g., 'use generate_fake_data' vs 'generate_text'). No two tools can perform the same job.
All seven tools follow a predictable snake_case verb_noun pattern (compare_text, draft_email, generate_*, humanize_text), with no mixed naming conventions. The generation tools share a clear generate_ prefix while keeping unique objects.
Seven tools is well within the sweet spot and each one represents a distinct text-generation or text-processing capability. The set feels neither bloated nor thin.
The suite covers common text tasks: create prose, create specific formats (email/outline/SQL), fabricate data, rewrite, and compare. Minor gaps exist—no summarization, translation, or general-purpose edit tool—but they do not create dead ends for the stated purpose.
Compare two blocks of text line by line. Returns JSON { identical, linesCompared, changeCount, changes[] }, where each change carries a 1-based line number, a change of 'added' | 'removed' | 'modified', and the before/after text. Lines are matched by POSITION, not by content: this is not an LCS diff, so inserting one line near the top reports every following line as modified. There is no character-level or word-level detail, and no unified-diff patch output. Whitespace and case are significant; \r\n and \n line endings are treated the same. Runs locally and costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| text1 | Yes | The baseline text, reported as `before` in each change. | |
| text2 | Yes | The revised text, reported as `after` in each change. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden, and it does: it discloses position-based matching, the lack of LCS behavior, the absence of patch output, whitespace/case significance, CRLF/LF normalization, and local execution cost. This is exemplary transparency beyond the structured schema.
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?
Four dense sentences with no filler: return shape first, then algorithm behavior, then limitations, then normalization/execution details. Every sentence contributes essential information for correct invocation.
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?
Despite having no annotations and no output schema, the description fully specifies the return contract, algorithm semantics, edge-case handling, and cost characteristics. An agent has everything needed to select and call 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 description coverage is 100% and the property descriptions already map text1 to baseline/before and text2 to revised/after. The main description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with a specific verb and resource ('Compare two blocks of text line by line') and immediately states the exact JSON return shape. The contrast with generation-oriented siblings like generate_text and draft_email is clear 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?
Clearly states the tool is position-based and not an LCS diff, and explicitly rules out character-level, word-level, and unified-diff use cases. It does not name a sibling alternative, but none of the sibling tools are diff tools, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a business email body from a short brief. Returns JSON { email, cached } containing the body only — no subject line, no recipient, and nothing is sent anywhere. Choose this over generate_text when the output should be a whole email; use humanize_text to rewrite an email you already drafted. Paid model call. Anonymous callers get 3 per hour per IP and are then refused with 401; signed-in callers get 15 per minute per IP. Length is capped at roughly 400 tokens. Identical briefs may return a cached draft.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Register of the writing. Default formal. Passed to the model as an instruction, so it shapes wording rather than enforcing a fixed template. | |
| prompt | Yes | What the email needs to say: purpose, recipient context, and any facts to include. A sentence or two is enough. Required and must not be blank. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It reveals pricing implications ('Paid model call'), rate limits and refusal status (401), output length cap (~400 tokens), caching behavior, and the important side-effect guarantee that nothing is sent. This is unusually transparent.
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?
Every sentence adds value: purpose, output shape, side-effect guarantee, sibling routing, rate limits, token cap, and caching. Information is front-loaded and the description stays compact despite covering many operational 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?
Despite having no annotations and no output schema, the description covers the return format, behavioral constraints, rate limits, caching, and usage boundaries. An agent has enough information to decide whether to call this tool and to interpret the response.
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 already documents both parameters. The description adds context about the brief ('A sentence or two is enough') but does not materially expand parameter semantics beyond the schema. Baseline 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?
States a specific verb and resource: 'Write a business email body from a short brief.' It immediately clarifies scope by saying the result is the body only, no subject line, no recipient, and nothing is sent. This clearly differentiates it from generate_text and humanize_text.
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?
Provides explicit selection guidance: 'Choose this over generate_text when the output should be a whole email; use humanize_text to rewrite an email you already drafted.' This tells the agent exactly when to pick this tool and when to pick an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a markdown heading structure for a blog post — title, introduction, numbered sections with subsections, conclusion and an FAQ block. Returns JSON { outline } holding the markdown. It writes the skeleton only, not the article: use generate_text for body prose and humanize_text to rework text that already exists. Paid model call, capped at roughly 1,000 tokens, so a large section count yields thinner sections. 10 calls per minute per IP; identical requests may return a cached outline.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The subject of the post, or a comma-free keyword phrase to build it around. The first thing supplied is treated as the primary keyword and the rest as secondary keywords to work in. | |
| sections | No | How many main sections to plan between the introduction and the conclusion. Default 5; a non-numeric or zero value also falls back to 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals the return format (JSON { outline }), the fact it writes only a skeleton, that it is a paid model call with a token cap, rate limiting, and caching behavior. This is substantial and actionable context.
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 dense but every sentence contributes unique information: purpose, return format, scope and alternatives, cost/token cap, rate limit and caching. It is front-loaded with the core function and keeps all sentences relevant.
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 tool with no annotations and no output schema, the description covers all necessary ground: what it does, what it returns, how it differs from siblings, and operational constraints. Nothing critical is missing for an agent 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that a large section count yields thinner sections due to the token cap, which is behavioral context tied to the 'sections' parameter that the schema does not 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 clearly states the tool produces a markdown heading structure for a blog post with specific components (title, introduction, sections, conclusion, FAQ). It explicitly distinguishes itself from generate_text and humanize_text, making the resource and scope unmistakable.
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 guidance: use this tool for the skeleton only, and use generate_text for body prose and humanize_text for reworking existing text. This gives clear when-to-use and when-not-to-use signals relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce placeholder person records for testing and fixtures. Returns JSON { type, count, records } where records is an array of strings, or of objects when type is 'user'. The values are drawn from a fixed word list by index, so they are DETERMINISTIC: the same arguments always return the same records, and asking twice does not give you fresh data. Emails all use example.com and phone numbers all use the +1-555 reserved range. It fabricates people only — for lorem-style prose use generate_text.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Shape of each record. 'name', 'email', 'address' and 'phone' each return a plain string; 'user' returns an object with all four fields. Required; any other value is rejected. | |
| count | No | How many records to return. Default 1, clamped to the range 1-100, and truncated to a whole number. Records are always the same sequence, so count 10 is the first 5 of count 5 plus 5 more. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does well by revealing deterministic outputs, fixed word-list behavior, reserved email/phone domains, and per-type return shapes. It could explicitly state that no data is persisted or that the operation is side-effect-free, but this is a minor gap for a fake-data generator.
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?
Three sentences, all information-dense. Purpose is first, return shape follows, then behavioral warnings and the sibling alternative are packed in 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?
The tool is simple with only two parameters and full schema coverage. The description covers the output format, deterministic behavior, restricted fake-value domains, and points to the correct sibling for prose generation. 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 coverage is 100%, so the parameters are already documented. The description adds real value by explaining the deterministic sequence behavior across counts and by clarifying that 'user' returns an object while other types return strings—semantics beyond the schema alone.
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: 'Produce placeholder person records for testing and fixtures.' It details the return shape and explicitly contrasts with generate_text for lorem-style prose, making it easy to distinguish from the siblings.
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 when to use the tool (testing/fixtures) and explicitly names generate_text as the alternative for prose. It also scopes the tool to 'people only,' giving a clear boundary for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a natural-language request into a SQL statement. Returns JSON { sql } containing the query text and nothing else — no validation report, no complexity score, and the query is never executed or checked against a real database. It has no knowledge of your schema beyond what the request states, so table and column names are guesses unless you supply them. Review before running, especially anything that writes. Paid model call. Anonymous callers get 3 per hour per IP and are then refused with 401; signed-in callers get 15 per minute per IP. Capped at roughly 500 tokens. Answers are cached, so the same request returns the same query.
| Name | Required | Description | Default |
|---|---|---|---|
| dialect | No | Intended SQL dialect. Accepted for forward compatibility but NOT currently passed to the model, so the generated SQL is generic and may need adjusting for your engine. | |
| description | Yes | What the query should do, in plain language. Include the table and column names you want used, otherwise the model invents plausible ones. Required and must not be blank. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the query is never executed or checked against a database, that names are guessed unless supplied, that results are cached, that there are rate limits and a 401 refusal, that the call is paid, and that output is capped around 500 tokens. This is exemplary disclosure.
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 dense but every sentence adds necessary operational or behavioral detail. It is front-loaded with the core purpose, then returns the contract, limitations, cautions, quotas, and caching behavior. No filler is present.
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 generation tool with no output schema and no annotations, the description is remarkably complete. It covers the return format, what is not returned, execution behavior, schema knowledge limitations, cost, rate limits, token cap, and caching, leaving little ambiguity for an agent choosing or invoking the 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?
Schema coverage is 100%, so the baseline is 3, and the description adds meaningful context beyond the schema. It explicitly notes that dialect is accepted for forward compatibility but not passed to the model, and it advises the caller to include table and column names in description because the model otherwise invents plausible ones.
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: 'Translate a natural-language request into a SQL statement.' It clearly identifies the tool's function and distinguishes it from text-focused siblings like generate_text and draft_email by naming SQL and the expected { sql } return shape.
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 actionable guidance: include table and column names in the request, review output before running, and be especially careful with writes. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough for an agent to decide when SQL generation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate filler prose — lorem ipsum, random copy or sentences — for mockups and placeholder content. Returns JSON { text, provider, cached } with the blocks separated by newlines. A language model writes it, so it is a paid call and the output is approximate: type, length and count are phrased into the prompt rather than enforced, and the result will not match a requested character count exactly. For placeholder people (names, emails, addresses) use generate_fake_data, which is exact, free and deterministic. For a real email use draft_email, and to rework existing text use humanize_text. 15 calls per minute per IP; capped at roughly 1,500 tokens; identical requests may return a cached result.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Flavour of filler to ask for: classic latin lorem ipsum, arbitrary English copy, or standalone sentences. Default lorem. Used as a prompt hint, so it steers the style rather than guaranteeing it. | |
| count | No | How many separate blocks to return. Default 1. Large values are bounded in practice by the ~1,500 token output cap. | |
| length | No | Rough size of each block in characters. Default 100. Requested in the prompt, so treat it as a target, not a limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it delivers: return shape ('Returns JSON { text, provider, cached }'), approximate behavior ('phrased into the prompt rather than enforced'), cost ('a paid call'), and limits ('15 calls per minute per IP; capped at roughly 1,500 tokens; identical requests may return a cached result'). This is rich behavioral disclosure for a non-deterministic 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?
Dense but every sentence earns its place: purpose → return format → behavioral caveats → sibling routing → operational limits. The most decision-relevant information (scope and alternatives) is front-loaded ahead of the caveats, and 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?
For a non-deterministic, paid, rate-limited tool with no annotations and no output schema, the description covers everything an agent needs: return format, approximation behavior, caching, rate limits, token cap, and alternative tools. The schema handles the parameters; the description handles the rest.
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% and each parameter already carries a detailed description covering defaults, the enum values, and the prompt-hint semantics. The description reinforces these traits ('type, length and count are phrased into the prompt rather than enforced') but adds little per-parameter meaning beyond what the schema already states, 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?
States a specific verb and resource ('Generate filler prose') plus the exact use case ('for mockups and placeholder content'), and enumerates the three flavours (lorem ipsum, random copy, sentences). The closing sentences name the sibling tools it is not (generate_fake_data, draft_email, humanize_text), so an agent can distinguish it from every alternative without opening their schemas.
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 routes to alternatives with conditions: 'For placeholder people ... use generate_fake_data, which is exact, free and deterministic', 'For a real email use draft_email', and 'to rework existing text use humanize_text'. It also states operational constraints (15 calls/minute, ~1,500 token cap, caching). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite text you already have so it reads less like model output — fewer stock phrases, more contractions, varied sentence rhythm. Returns JSON { humanizedText }. Meaning is meant to be preserved but wording is not: never use it on text that must stay verbatim, such as quotes, legal copy or code. Use generate_text to produce new prose from a prompt and draft_email for a whole email; this one only transforms text it is given. Requires a signed-in razi.pro account — an anonymous call is rejected with 401. Paid model call; input capped at 10,000 characters and output at roughly 2,000 tokens, so long passages come back truncated. 30 calls per hour per account, and identical inputs may return a cached result.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The passage to rewrite. Plain text. Maximum 10,000 characters; longer input is rejected with 413. | |
| level | No | How far the rewrite may drift from the original voice. 'light' strips AI tells but stays professional, 'medium' (the default, also used for any unrecognised value) turns it conversational with contractions, 'strong' rewrites it casually with short punchy sentences. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers richly: it discloses the JSON return shape, the meaning-vs-wording preservation caveat, the authentication requirement with 401 rejection, the paid-model nature, input/output limits and truncation, the rate limit of 30 calls/hour, and the possibility of cached results for identical inputs.
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?
Although relatively long, every sentence earns its place: core function, output shape, verbatim-use warning, sibling routing, auth, cost, limits, rate limit, and caching. It is dense but logically ordered and front-loaded with the purpose, not 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?
Given the absence of annotations and an output schema, the description is remarkably complete for a paid, restricted, truncation-prone tool. It covers input constraints, output format, failure modes (401, 413 implied), rate limits, caching, and the semantic caveat, leaving no critical gap for an agent to call it safely.
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 baseline is 3. The description repeats the 10,000-character input cap and adds output-truncation context, but it adds no meaning for the level parameter beyond the schema's already-complete enum explanation. It does not compensate beyond 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 opens with a specific verb and resource ('Rewrite text you already have so it reads less like model output'), clearly distinguishing it from generation tools. It explicitly names siblings generate_text and draft_email and states that 'this one only transforms text it is given,' so an agent can disambiguate it from the other tools in the set.
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 and when-not-to-use guidance. It says to use generate_text for new prose and draft_email for whole emails, and warns against using this tool on text that must stay verbatim such as quotes, legal copy or code. This directly routes the agent to the correct sibling.
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.
compare_textdraft_emailgenerate_blog_outlinegenerate_fake_datagenerate_sqlgenerate_texthumanize_textClaiming 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!
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
