20 content-creation persona and skill products plus real writing analyzers over MCP: analyze_writing measures readability and style issues, headline_analyzer ranks up to 20 headlines, reading_time and social_length_check validate platform fit, and get_free_skill loads any product's complete free gateway skill.
Analyze a draft for readability, passive voice, cliches, and hedging. FREE.
Also measures sentence variety and keyword density, and produces a prioritized fix list. Typical input {"text": ""} returns {"readability_grade": 9.2, "passive_voice_count": N, "cliches_found": [...], "hedging_words": [...], "sentence_count": N, "avg_words_per_sentence": N, "top_repeated_words": [...], "priority_fixes": ["..."]}.
Use on body prose to find readability and style problems. Not for ranking titles (headline_analyzer) and not for platform limits (social_length_check). 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 draft to analyze — at least one full sentence; plain text, any length. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral details beyond readOnly and idempotent annotations: it never raises protocol errors but returns an error object, and includes sample output structure. This enriches the agent's understanding of expected behaviors.
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 clear purpose, example output, usage notes, and error handling, all in a compact form. Every sentence provides value, and key points are 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 single-parameter tool with full schema coverage and an output schema, the description is comprehensive: it covers usage, errors, retry safety, and sample output, leaving little ambiguity.
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 schema covers 100% of the parameter, and the description reiterates the typical input format and adds constraints like 'at least one full sentence' and 'plain text', which go beyond schema essentials.
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 drafts for readability, passive voice, cliches, and hedging, and lists additional metrics. It distinguishes itself from siblings by explicitly noting it's not for titles or platform limits.
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 explicitly says to use on body prose and not for ranking titles or checking social length limits, naming alternatives (headline_analyzer, social_length_check). This is 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 a product's free gateway skill with its complete instructions. FREE.
Typical input {"slug": "brand-voice"} returns {"slug": "brand-voice", "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. "brand-voice". |
| 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 goes beyond by explaining error behavior: 'never raises a protocol error — it returns an error object' and that after correcting input it is 'always safe to retry'. This adds critical behavioral context above 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: it opens with the core purpose, then provides an input/output example, usage guidelines, differentiation from sibling, error handling, and safety guarantees. Every sentence adds value, and there is no unnecessary repetition or jargon.
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 single-parameter tool with output schema and clear annotations, the description covers everything needed: purpose, usage context, error recovery, and linkage to list_products for valid slugs. It is complete for an agent to select and invoke the tool correctly without additional information.
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 already states the slug must be exactly as returned by list_products. The description adds a concrete example and clarifies the slug determines which skill is loaded, but does not provide additional semantics beyond what the schema covers. 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?
The description states it loads a product's free gateway skill with complete instructions, specifying it returns exactly one skill chosen automatically from the slug. It explicitly differentiates from get_full_skill, which handles other skills and requires a paid plan. This provides a specific verb-resource scope and clear sibling distinction.
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 warns '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 gives clear when-to-use and when-not-to-use guidance, along with the alternative tool.
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": "brand-voice"} 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. "brand-voice". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds error behavior details (never raises protocol error, returns error object with fix guidance) and reaffirms idempotency/read-only nature, providing valuable context 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?
Description is well-structured with a front-loaded purpose, example, usage guidance, error handling, and idempotency note. Every sentence adds value, 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 presence of an output schema, the description compensates with a JSON output example. It covers licensing, error behavior, retry safety, and distinction from sibling tools. Sufficient for a simple 1-parameter 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 description coverage is 100% with a clear parameter description. The description adds an inline example of typical input, which reinforces parameter usage but doesn't add substantial new meaning beyond the schema. Baseline 3 with slight improvement for contextual example.
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 it loads a full product with persona and all paid skills, using specific verbs and resource. It distinguishes from siblings like get_full_skill and list_products, making 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?
Explicitly states when to use 'when the caller wants the whole product' and when not—for single skill or free look—naming specific alternative tools (get_full_skill, list_products, get_free_skill). Also mentions license requirement.
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": "brand-voice", "skill_name": "Voice Audit"} 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. | |
| skill_name | Yes | Exact skill name as listed in that product's "skills" array from list_products. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: error handling details ('never raises a protocol error — it returns an error object'), retry safety, and idempotency. Annotations already declare readOnlyHint and idempotentHint, and the description reinforces these with practical implications. No contradiction.
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 well-structured: front-loaded with main purpose, then example, usage guidelines, error handling, and idempotency note. Every sentence adds value with no redundant or vague phrasing.
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 (2 parameters, 100% schema coverage, clear annotations, output schema), the description is complete. It covers purpose, usage, error behavior, and safety, leaving no gaps for an agent to infer.
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 well. The description provides an example but does not add new semantic meaning beyond what the schema provides. 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?
Description clearly states the tool loads one paid skill's complete instructions from a product. It provides a typical input/output example and distinguishes from siblings: get_free_skill for free gateway skill and get_full_product for all skills at once. The verb 'load' is specific and the resource is well-defined.
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: 'Use when the caller wants one specific paid skill.' Also lists exclusions: 'Not for the free gateway skill... and not for every skill at once (get_full_product).' This provides clear guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score and rank up to 20 headlines, best first. FREE.
Scores 0-100 on length, power/emotion words, numbers, structure, and clarity. Typical input {"headlines": ["7 Mistakes New Writers Make", "On Writing"]} returns {"ranked": [{"headline": ..., "score": 85, "notes": ["good length", "contains number"]}, ...]}.
Use when several title options need ranking. Not for email subject lines, which the outbound server's subject_line_scorer judges against deliverability signals, and not for body prose (analyze_writing). 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 |
|---|---|---|---|
| headlines | Yes | List of candidate headlines as plain strings; only the first 20 are scored. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by clarifying the error behavior (returns error object, never raises protocol errors), the 20-headline limit, and the scoring dimensions. However, it doesn't mention whether the order of ties is deterministic or any rate limits. Still, with strong annotations, the bar is low, and the added context is helpful.
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 reasonably concise at ~6 sentences, with critical info front-loaded (purpose, free, example). The second paragraph adds usage guidelines and error behavior efficiently. Minor structural improvement: the error handling sentence could be a separate paragraph, but overall it's well-organized and every sentence earns its place.
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 covers purpose, usage boundaries, input/output example, error handling, idempotency/read-only safety, and points to relevant siblings. Given the tool's simplicity (1 param, clear schema, rich annotations, output schema present), this is a complete and self-sufficient description that leaves little ambiguity for an AI agent.
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 the single parameter ('headlines') well, including that only the first 20 are scored. The description reinforces this with an example but adds little new about parameter syntax or constraints beyond what the schema provides. Baseline 3 is correct.
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 starts with a specific verb ('Score and rank'), names the resource ('headlines'), and clarifies the scope ('up to 20 headlines, best first'). The example input/output reinforces the purpose, and it clearly distinguishes from siblings like analyze_writing which handles body prose.
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 states when to use ('several title options need ranking') and provides clear exclusion criteria: 'Not for email subject lines' (pointing to subject_line_scorer) and 'not for body prose' (pointing to analyze_writing). It also discusses error handling and retry safety, giving the agent full context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every product in the Creator Studio line with its included skills. FREE.
Takes no arguments. Returns a list of 20 product objects, each {"slug": "brand-voice", "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?
The description goes beyond the annotations by disclosing that the tool never raises protocol errors on invalid input, instead returning an error object with fix instructions. It also states the return format precisely (list of 20 product objects with slug, name, tagline, skills, free_skill) and confirms read-only idempotent behavior, reinforcing the readOnlyHint and idempotentHint annotations without contradiction.
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 essential purpose in the first sentence, followed by structured details on arguments, return format, usage guidance, error behavior, and safety. Every sentence adds meaningful information without redundancy or fluff. At 8 sentences, it is appropriately sized for the tool's complexity and sibling context.
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 zero parameters, an output schema, and annotations that already cover read-only/idempotent behavior, the description adds complete context: return structure, error handling, usage scenarios, and sibling differentiation. There are no gaps—the agent has everything needed to decide when and how to call this 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%, and the description explicitly states 'Takes no arguments,' which adds clarity beyond the empty schema. While there's nothing to add about individual parameters, the description compensates by explaining the return format and usage of slug values, which is actionable context for the agent.
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 uses a specific verb ('List'), identifies the exact resource ('every product in the Creator Studio line'), and clarifies the scope ('with its included skills. FREE.'). It also explicitly distinguishes itself from siblings by stating what the tool does NOT return (no persona text, no instructions) and by naming sibling tools for further actions (get_free_skill, get_full_product, get_full_skill). This makes the purpose 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 tells the agent exactly when to use this tool ('when the caller wants to see what this server covers') and when not to ('Not for keyword search...use catalog server's search_catalog'). It also clarifies what the tool is not suited for ('not for instructions the caller can act on') and suggests alternatives (get_free_skill). This is explicit, clear guidance with exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate reading and speaking time plus basic content stats. FREE.
Typical input {"text": ""} returns {"words": 1200, "reading_minutes": 5.2, "speaking_minutes": 8.6, "paragraphs": 14, "fit": "newsletter/blog"}.
Use when length and pacing are the question. Not for writing quality or grade level (analyze_writing). 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 |
|---|---|---|---|
| wpm | No | Silent reading speed in words per minute; values below 60 are treated as 60. Default 230. | |
| text | Yes | The content to measure, plain text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds valuable context: it never raises protocol errors but returns an error object with fix guidance, and reaffirms read-only and idempotent behavior. 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 well-structured: opening purpose, example, usage guidance, error handling. No extraneous text. Slightly longer due to example, but all content earns its place.
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 2-parameter tool with full schema coverage, output schema, and annotations, the description covers all necessary aspects: purpose, when to use, error handling, and behavior. No gaps remain.
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?
Input schema covers 100% of parameters with descriptions. The description does not add semantic meaning beyond the schema; it provides an example of typical input and output but does not elaborate on parameters themselves. 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?
The description clearly states the tool estimates reading and speaking time plus basic content stats. It explicitly distinguishes itself from the sibling tool 'analyze_writing' by noting it is not for writing quality or grade level.
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 tells when to use (when length and pacing are the question) and when not to use (not for writing quality/grade level), naming the alternative 'analyze_writing'. This provides clear decision support.
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.
analyze_writingget_free_skillget_full_productget_full_skillheadline_analyzerlist_productsreading_timesocial_length_checkClaiming 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.
Each tool has a clearly distinct purpose: prose analysis, headline scoring, reading stats, platform length check, product listing, free/paid skill retrieval, and full product details. There is no ambiguity between any pair of tools, and descriptions explicitly note what not to use them for.
All tool names use consistent snake_case verbs followed by nouns (e.g., analyze_writing, list_products, get_free_skill). Even reading_time and social_length_check follow the pattern, albeit with nouns first, but the style is uniform and predictable.
With 8 tools, the server is well-scoped. It covers both content analysis (4 tools) and product catalog access (4 tools) without overloading or underrepresenting either domain. The number feels appropriate for a focused studio toolkit.
The tool set covers the core functions of a Creator Studio: writing analysis, headline optimization, reading time, social length checks, plus full product catalog introspection. Minor gaps like grammar checking or content generation exist but are outside the stated scope. The set has no dead ends for the intended workflows.
social_length_checkSocial Length CheckARead-onlyIdempotent Inspect
Check a post against every major platform's length limit at once. FREE.
Covers X, LinkedIn posts and headlines, Instagram captions, Threads, YouTube titles, and meta descriptions. Typical input {"text": ""} returns {"chars": N, "platforms": {"x_post": {"limit": 280, "fits": true, "over_by": 0}, ...}}.
Use before posting, to catch truncation. Not for readability (analyze_writing) and not for reading duration (reading_time). 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.
Output Schema
No output parameters
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds detailed behavioral traits: the tool never raises protocol errors on invalid input, returns a structured error object, and is always safe to retry. This provides valuable context not present in annotations alone.
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, front-loaded with the core purpose, and every sentence adds meaningful information (usage, example, error behavior, safety). No unnecessary words 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 tool with one parameter, read-only semantics, and a predictable output (example given), the description covers purpose, usage, error handling, and retry safety. It is fully sufficient for an agent to select and invoke this 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 clear description of the 'text' parameter. The description adds example input format but no additional meaning beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the load.
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 checks a post against every major platform's length limit at once, listing specific platforms (X, LinkedIn, Instagram, etc.). It distinguishes itself from sibling tools like analyze_writing and reading_time by explicitly noting what it does not cover.
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 before posting, to catch truncation. Not for readability (analyze_writing) and not for reading duration (reading_time).' It also explains error handling and that retries are safe, giving the agent clear context for when and when not to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.