Generate, render, and host Slidev presentations from markdown
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: browsing themes visually vs. listing them textually, getting the syntax guide vs. theme documentation, rendering, exporting, screenshotting, and listing session slides. Even the two theme-related tools are separated by user-facing vs. agent-facing intent.
All tool names follow a consistent verb_noun pattern in snake_case: browse_themes, export_slides, get_slidev_guide, get_theme, list_session_slides, list_themes, render_slides, screenshot_slides. The naming is uniform and predictable.
With 8 tools, the set is well-scoped for the Slidev presentation domain. Each tool covers a distinct step in the workflow—learning syntax, selecting themes, rendering, reviewing, exporting, and managing session output—without redundancy.
The tool surface covers the full lifecycle: syntax reference, theme discovery and documentation, rendering, visual review via screenshots, PDF export, and session listing. Since presentations are rendered from markdown, re-rendering serves as the update mechanism, so no critical operations are missing.
browse_themesBrowse ThemesAShow the user a visual theme gallery with preview images.
ONLY call this when the user explicitly asks to SEE or BROWSE themes visually (e.g. "show me the themes", "what do they look like", "let me pick a theme"). This renders an interactive gallery in the user's UI.
To show a filtered subset (e.g. only dark themes), first call list_themes to identify matching themes, then pass their names here.
Do NOT call this to decide which theme to use yourself — use list_themes for that instead.
| Name | Required | Description | Default |
|---|---|---|---|
| themes | No | Optional list of theme names to show (e.g. ['dracula', 'neocarbon', 'vibe']). If omitted, all themes are shown. Use list_themes first to find matching themes, then pass the filtered names here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that this tool 'renders an interactive gallery in the user's UI', which is a UI side effect beyond the annotations. It also notes a dependency on list_themes for filtered subsets, providing useful workflow 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 concise and well-structured, leading with the core purpose, then providing clear conditional usage rules. Every sentence adds value without 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?
For a simple tool with one optional parameter and no output schema, the description fully covers purpose, when to use, how to filter, and alternative tools. It is complete and self-contained.
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 parameter is already well-documented. The description repeats the same guidance about passing theme names or omitting to show all, but it does not add new semantics beyond what the schema already 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?
The description clearly states the tool's purpose: 'Show the user a visual theme gallery with preview images.' It uses a specific verb and resource, and is distinct from sibling tool list_themes, which lists themes without visual preview.
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 when-to-use guidance is given: 'ONLY call this when the user explicitly asks to SEE or BROWSE themes visually.' It also states when not to use it ('Do NOT call this to decide which theme to use yourself') and prescribes alternatives like list_themes for non-visual selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_slidesExport Slides as PDFAInspectExport a presentation as a downloadable PDF.
The presentation must have been created in the current session. Returns a URL to download the PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the presentation to export. Must be from the current session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output (a URL to download the PDF) and the session constraint, which are useful but not entirely new since the schema already mentions the session requirement. The annotations only say readOnlyHint=false, leaving the description to carry the behavioral burden. It does not describe side effects, asynchronicity, or any error conditions, but for a simple export tool it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear action sentence and one sentence for constraint/output. It is front-loaded with the purpose and contains no fluff or repetition. Every word 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 tool with a single parameter and no output schema, the description covers the essential aspects: what it does, the session prerequisite, and the return value. It doesn't explain error cases or elaborate on the export process, but given the tool's simplicity, it is complete enough for an agent to 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 description coverage is 100%, so the parameter 'uuid' is well documented in the schema, including the session requirement. The description merely repeats this constraint without adding new meaning, matching the baseline score of 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 'Export' with the resource 'a presentation as a downloadable PDF', which is specific and distinct from siblings like render_slides or screenshot_slides. The additional session constraint 'must have been created in the current session' further clarifies the exact scope of the tool.
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 a clear context for use: when you need to export a presentation as a PDF, and it explicitly states a prerequisite (must be from the current session). However, it does not explicitly mention alternatives or when not to use this tool, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_slidev_guideGet Slidev GuideAGet the Slidev syntax guide: how to write slides in markdown.
Returns the official Slidev syntax reference (frontmatter, slide separators, speaker notes, layouts, code blocks) plus built-in layout documentation and an example deck. Call this once to learn how to write Slidev presentations.
| 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 the readOnlyHint and openWorldHint annotations, the description adds specific behavioral detail: it 'returns the official Slidev syntax reference' and lists the exact components (frontmatter, slide separators, speaker notes, layouts, code blocks) plus layout docs and an example deck. This sets accurate expectations without conflicting 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?
Three sentences, front-loaded with the core purpose, then enriching details, and finally a usage directive. Every sentence earns its place with 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?
For a simple, zero-parameter reference tool with an output schema, the description fully covers what the agent needs to know: the scope of the guide, its contents, and when to call it. It is complete in context, especially given the sibling tools are about themes/rendering rather than syntax learning.
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 tool has zero parameters and 100% schema coverage (vacuously). The description adds value by detailing what the guide contains, which is more useful than simply saying 'no parameters.' Baseline for 0 params is 4, and the extra content detail supports this score.
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 and resource: 'Get the Slidev syntax guide' and explicitly states what it does ('how to write slides in markdown'). It distinguishes itself from sibling tools like browse_themes or list_themes by focusing on the syntax guide rather than themes or rendering.
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 clear usage guidance: 'Call this once to learn how to write Slidev presentations.' This tells the agent when to invoke it (before authoring slides) and implies a single call is sufficient. It does not explicitly mention alternatives, but the guide's uniqueness makes this unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_themeGet Theme DetailsAGet full documentation for a specific theme: layouts, components, and examples.
Call this BEFORE render_slides to learn the theme's unique features. Each theme has different layouts, components, and frontmatter options. Use what you learn here to produce high-quality, theme-specific slides.
This is the primary tool for preparing to render slides. When the user specifies a theme, call this directly — no need to call browse_themes.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | Yes | Theme name (e.g. 'seriph', 'neocarbon', 'field-manual'). Available themes: default, seriph, apple-basic, bricks, shibainu, academic, cobalt, dracula, eloc, field-manual, frankfurt, geist, neocarbon, neversink, nord, penguin, purplin, scholarly, swiss-ai-hub, the-unnamed, unicorn, vibe, vuetiful, zhozhoba. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds behavioral context by explaining that 'Each theme has different layouts, components, and frontmatter options' and that it should be used before render_slides, which informs the agent's workflow 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 front-loaded with the purpose, but contains some redundancy: 'Call this BEFORE render_slides' and 'This is the primary tool for preparing to render slides. When the user specifies a theme, call this directly' cover similar ground. Still, it is relatively compact and every sentence adds either purpose or usage 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's simplicity (1 parameter, output schema present, annotations provided), the description is complete: it explains what the tool returns (layouts, components, examples), when to use it, and how it relates to siblings. The output schema covers return format, so no further details are needed.
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 has 100% description coverage, including a list of available themes and examples, so the description doesn't need to add parameter details. It only refers to 'a specific theme' without extra syntax or format info, matching the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get full documentation for a specific theme: layouts, components, and examples.' It clearly distinguishes from browse_themes with 'no need to call browse_themes,' matching the high calibration example.
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 when-to-use guidance is provided: 'Call this BEFORE render_slides' and 'When the user specifies a theme, call this directly.' It also gives a when-not/alternative: 'no need to call browse_themes,' satisfying the 5-point criterion for explicit when/when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_session_slidesList Session SlidesAList all slide presentations created in the current MCP session.
Returns URLs, themes, and timestamps for each presentation you've created.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| slides | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint: true, so the description adds value by specifying the return content (URLs, themes, timestamps) and the session-scoped nature. This provides behavioral context beyond the simple read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main action and scope, then a brief note on return values. No unnecessary words.
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 parameterless list tool with an output schema, the description covers the needed details: what it lists, scope, and return fields. The presence of the output schema further covers return structure.
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 tool takes no parameters; schema coverage is complete (100% of empty schema). The description adds no parameter-specific semantics but the 0-parameter baseline is satisfied.
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 and resource: 'List all slide presentations' with scope 'created in the current MCP session.' This clearly differentiates it from sibling tools like list_themes and export_slides, which handle different resources/actions.
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 implies use whenever you need to review slide presentations made during the current session. However, it doesn't explicitly state alternatives or when not to use it, so while context is clear, exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_themesList ThemesAGet a list of all available themes with style descriptions and recommendations.
Call this to decide which theme to use. Returns a guide organized by style (dark, academic, modern, playful, etc.) with "best for" recommendations.
After picking a theme, call get_theme with the theme name to read its full documentation (layouts, components, examples) before rendering.
This tool does NOT display anything to the user — it is for your own reference when choosing a theme.
| 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 readOnlyHint, the description reveals it returns a structured guide with 'best for' recommendations and explicitly states it displays nothing to the user. This adds meaningful behavioral 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?
Four sentences, each earning its place: purpose, usage context, return format, next step, and a critical non-display note. No fluff, front-loaded with the main action.
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 zero-parameter read-only tool with an output schema, the description covers purpose, when to use, return structure, and follow-up actions. It fully compensates for any missing details and integrates with sibling tools.
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 tool has zero parameters, so the baseline is 4. The description adds value by describing what the returned list contains (style organization, recommendations), though no parameter explanations are needed.
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?
Clearly states the tool lists all available themes with style descriptions and recommendations, using a specific verb and resource. Distinguishes itself from sibling get_theme by clarifying it's a high-level guide, not full documentation.
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 instructs to call this to decide which theme to use, then directs to call get_theme for full documentation. Also clarifies it's for the agent's own reference and does not display to user, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_slidesRender Slidev PresentationAInspectRender a Slidev presentation from markdown and return its hosted URL.
IMPORTANT: Before calling this tool, you MUST call get_theme with the theme name you plan to use. Each theme has unique layouts, components, and frontmatter options. Apply the theme's specific features in your markdown to produce high-quality slides that match the theme's design.
If the user has not specified a theme, call list_themes to pick one. If you are unfamiliar with Slidev markdown syntax, call get_slidev_guide.
Images must be remote URLs or base64-encoded inline. Local file paths are not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | UUID of an existing presentation to update in-place (same URL). Omit to create a new presentation. | |
| theme | Yes | Theme name (e.g. 'seriph', 'default', 'neocarbon'). Read slidev://themes/installed for the full list of available themes. | |
| markdown | Yes | Full Slidev markdown including frontmatter. Use layouts, components, and features specific to the chosen theme. | |
| color_schema | No | Color scheme: 'light' (default), 'dark', or 'auto'. Controls whether slides render in light or dark mode. | light |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only note readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral context: it forces the caller to retrieve a theme first, and it codifies a critical input constraint ('Images must be remote URLs or base64-encoded inline. Local file paths are not supported'). It doesn't mention update-in-place behavior (via uuid) or auth requirements, but the schema covers the uuid parameter. The description aligns with annotations and adds substantial 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 front-loaded with the core purpose in the first sentence, then uses a clearly marked 'IMPORTANT' section for prerequisites, followed by conditional alternatives and a final constraint. Every sentence earns its place: no filler, no repetition of schema field descriptions, and the structure makes it easy for an agent to parse the critical workflow steps.
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 that this tool has 4 parameters, no output schema, and no enums, the description provides all necessary operational context: it explains the output (hosted URL), the mandatory prerequisite (get_theme), and the markdown image constraint. It also tells the agent how to recover if a theme isn't specified or if syntax is unfamiliar. The description is sufficiently complete for an agent to invoke the tool correctly on its own.
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 already covers all 4 parameters with 100% description coverage, giving a baseline of 3. The description adds value beyond the schema by explaining how to use the markdown parameter ('Use layouts, components, and features specific to the chosen theme') and by imposing the image-format constraint. This helps the agent construct valid inputs without needing to infer from terse schema fields.
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 clear, specific verb+resource statement: 'Render a Slidev presentation from markdown and return its hosted URL.' It distinguishes itself from sibling tools like export_slides (which exports) and screenshot_slides (which captures images) by emphasizing the hosted URL output. The description's focus on rendering from markdown to a hosted presentation is 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 provides explicit workflow guidance: 'Before calling this tool, you MUST call get_theme', 'call list_themes to pick one' if no theme, and 'call get_slidev_guide' if unfamiliar with syntax. These are clear alternatives and prerequisites. It also states when to use the tool (when you need a hosted URL) and gives a constraint (images must be remote or base64), which helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenshot_slidesScreenshot SlidesARender all slides as PNG images and return them.
Use this to visually review a presentation. Returns one image per slide so you can see exactly what each slide looks like and give specific feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the presentation to screenshot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is covered. The description adds behavioral detail by stating that it 'returns one image per slide,' which is useful context beyond the annotations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds value: the action, the use case, and the return format. There is no fluff 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?
With only one parameter and no output schema, the description covers the essential return behavior ('Returns one image per slide') and the purpose. It does not elaborate on potential performance implications or exact image encoding, but for a simple read-only tool with clear intent, it is sufficient. A 5 would require specifying these edge details.
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% for the single uuid parameter, which is described as 'UUID of the presentation to screenshot.' The description does not add additional meaning about the parameter or its format, so the baseline score of 3 applies per the rubric.
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 function: 'Render all slides as PNG images and return them.' It uses a specific verb ('render') and resource ('all slides'), and the phrase 'visually review a presentation' distinguishes it from siblings like export_slides or render_slides that may serve different output purposes.
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 this to visually review a presentation,' giving clear context for when to invoke the tool. However, it does not mention exclusions or alternative tools explicitly, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.