mkdshare.DEV
Server Details
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4/5 across 9 of 9 tools scored. Lowest: 2.8/5.
Each tool has a clear, distinct purpose. Authentication tools are separated from document operations, and within documents, CRUD actions are distinct from annotation actions. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case, such as archive_document, create_annotation, poll_device_auth. No mixing of conventions.
9 tools is well-scoped for a document management server with authentication and annotations. It covers the necessary operations without being excessive or sparse.
Core document CRUD (create, get, update, archive, list) is covered. Annotations have create and list, but lack update/delete, which is a minor gap. No tool for sharing or permissions, but the main workflows are supported.
Available Tools
10 toolsarchive_documentAInspect
Archive a document. For documents you own, archives it for everyone. For shared documents, archives it only for you.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Document slug |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the different archival behavior based on ownership, which is critical. However, it does not mention reversibility, permissions, or side effects.
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 sentences, front-loaded with the main action, and no wasted 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 single-parameter tool with no output schema, the description covers the key behavioral nuance. It could elaborate on what 'archive' means (e.g., reversibility, visibility), but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds context for the action but does not significantly enhance the parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives a document and distinguishes behavior based on ownership (archives for everyone vs. only for the user). This is a specific verb+resource with nuanced behavior.
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 explains when the tool affects everyone vs. only the user, providing context for its use. However, it does not explicitly compare with siblings like update_document or delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_annotationAInspect
Add an annotation (comment) to a document. Pass quoted_text with the exact passage you want to annotate — the server will locate it automatically. Omit quoted_text to attach to the whole document. You can also provide start_offset + end_offset explicitly if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Annotation text | |
| slug | Yes | Document slug | |
| end_offset | No | Character offset where annotation ends | |
| quoted_text | No | The exact text being annotated | |
| start_offset | No | Character offset where annotation starts |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behaviors. It explains that the server automatically locates quoted_text and that offsets can be used. However, it does not mention permissions, reversibility, or other side effects, which would be helpful for a creation 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?
Two sentences with no waste. The first states the purpose, the second explains the parameter usage. Front-loaded and easy to parse.
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 5 parameters and no output schema, the description covers main usage patterns well. It could mention that the tool returns the created annotation, but it's not critical. Overall sufficient 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?
The description adds significant meaning beyond the input schema: it explains the relationship between quoted_text and offsets, and the behavior when quoted_text is omitted. This helps the agent choose the right parameters for the intended annotation type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('add an annotation') and the resource ('document'). It distinguishes itself from 'list_annotations' by being the creation counterpart, and it uniquely targets annotation tasks among 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 provides clear usage patterns: pass quoted_text for specific passage, omit for whole document, or use offsets. It implicitly tells when each parameter combination is appropriate, but lacks explicit when-not or alternative tool mentions. Since no alternative annotation creation exists, this is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_documentCInspect
Create a new mkdshare.DEV document.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Document title | |
| content | Yes | Markdown content | |
| expires_at | No | ISO 8601 datetime after which the document expires, e.g. 2026-06-01T00:00:00Z | |
| visibility | No | Who can view the document (default: public) | |
| editor_emails | No | Comma-separated emails that can edit this document (in addition to the owner) | |
| allowed_domain | No | Domain allowed to view, e.g. company.com (domain_restricted visibility) | |
| allowed_emails | No | Comma-separated emails allowed to view (login_required visibility) | |
| domain_can_edit | No | When true, all users in allowed_domain can edit (not just view) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'create' (mutation) but fails to specify side effects, permissions, rate limits, or return values. The minimal disclosure is insufficient for a tool with 8 parameters.
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 a single sentence with no wasted words, making it concise. However, it is too brief and lacks structure such as bullet points or sections, which would improve readability for complex tools.
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 8 parameters (including conditional fields like allowed_domain) and no output schema, the description is grossly incomplete. It omits crucial context such as return format, behavior on success/failure, and constraints, leaving the agent underinformed.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond what the schema provides, earning a 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 tool creates a new mkdshare.DEV document, distinguishing it from sibling tools like archive_document or update_document. However, it lacks details about what the document creation entails, and 'mkdshare.DEV' may not be immediately understood, slightly reducing clarity.
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?
No guidance is provided on when to use this tool versus alternatives. The description only says 'create', leaving the agent to infer the usage context without explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentAInspect
Read the full markdown content of a document by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 8-character document slug from the URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a non-destructive read operation but does not mention potential errors (e.g., document not found), authentication requirements, or rate limits. The description is adequate for a simple read but lacks depth.
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 a single sentence that is concise and front-loaded with the verb 'Read'. No extraneous words are present, and all information is efficiently conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is mostly complete. It specifies the resource and identifier. However, it could be enhanced by mentioning that the document must exist or that only markdown content is returned.
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% (the single 'slug' parameter is described in the schema). The description restates the same information from the schema without adding new semantics, resulting in a 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 action (Read), resource (full markdown content of a document), and the method (by its slug). It distinguishes from siblings like list_documents (lists instead of reads) and update_document (writes instead of reads).
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 does not explicitly state when to use this tool versus alternatives. Usage is implied by the verb 'Read' compared to sibling tools like create_document or update_document, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_annotationsAInspect
List all annotations (comments) on a document.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Document slug |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states it lists all annotations, without mentioning read-only nature, pagination, ordering, or any potential limits, offering minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (7 words) that conveys the essential purpose without any superfluous content, earning its place efficiently.
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 (one parameter, no output schema), the description is adequate for basic understanding but lacks details about the return format or any additional context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the slug parameter described as 'Document slug'. The description adds marginal value by clarifying the annotations are on a document, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'annotations (comments)' on a document. It effectively distinguishes from sibling tools like create_annotation and list_documents, leaving no ambiguity about the tool's function.
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 usage for listing annotations on a document but provides no explicit guidance on when to use this tool versus alternatives, nor any context about 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.
list_documentsAInspect
List all mkdshare.DEV documents owned by or shared with the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It only states it lists documents, without disclosing pagination, return format, or any side effects, which is insufficient for a read operation with zero annotation support.
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?
Single sentence with no unnecessary words, front-loading the key information about what the tool does and its scope.
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 no parameters and no output schema, the description is mostly complete for a simple list operation, but could benefit from mentioning whether results are paginated or if there are any limits.
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?
No parameters exist, so baseline 4 applies. The description accurately reflects the parameterless nature, adding no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all mkdshare.DEV documents owned or shared with the authenticated user, specifying the resource and scope, which distinguishes it from sibling tools like get_document or archive_document.
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 indicates when to use (to list all accessible documents), but does not explicitly mention when not to use or provide alternatives, such as using get_document for a specific document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
poll_device_authAInspect
Check whether the user has approved the device authorization. Call every 5 seconds (or the interval returned by a slow_down response) until status is 'complete'. Save the returned api_token to your MCP server config.
| Name | Required | Description | Default |
|---|---|---|---|
| device_code | Yes | device_code returned by request_device_auth |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the polling mechanism, response handling, and token management. However, it doesn't specify what happens if the user denies or if there are error conditions, but for a polling tool this is fairly 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?
Two sentences efficiently cover purpose, polling interval, response handling, and action. Front-loaded with clear verb and resource, 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?
Given one parameter, no output schema, and no annotations, the description adequately covers the polling loop and token saving. It could mention timeout or error handling, but for a simple poller it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter device_code is described in the schema as 'device_code returned by request_device_auth'. The description adds no extra semantic information about the parameter itself, so it meets the baseline for 100% 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 clearly states the tool checks whether user approved device authorization, and includes polling behavior. It references a sibling tool (request_device_auth) but doesn't explicitly differentiate from other sibling tools, though its polling nature is unique enough.
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 instructions: call every 5 seconds, handle slow_down response, check for 'complete' status, and save api_token to config. This leaves no ambiguity about when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_device_authAInspect
Start a headless Google sign-in. Call this FIRST if you don't have an API token yet. Returns a user_code and verification_url for the user to visit, plus a device_code to use with poll_device_auth. No Bearer token required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses the function returns user_code, verification_url, and device_code, and that no authentication is needed. Lacks mention of token expiration or rate limits, but still informative.
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 concise sentences, each adding value. Front-loaded with the key action and use-case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description fully covers the tool's role in the authentication flow, its output, and its relation to siblings. No gaps.
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?
No parameters defined; schema is empty. Description adds meaning by explaining the purpose and output, which is more than the schema provides. Baseline 4 for 0-param tools.
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 initiates a headless Google sign-in, specifies it's the first step if no token exists, and distinguishes itself from the sibling 'poll_device_auth'.
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 guides when to use ('call this FIRST if you don't have an API token yet'), what not to use (no Bearer token required), and mentions the next step ('poll_device_auth').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_documentsAInspect
Search mkdshare.DEV documents by title and content. Returns documents owned by or shared with the authenticated user that match the query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search string matched case-insensitively against document title and content |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states basic search and filtering but omits details like pagination, performance, or authentication requirements.
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 concise sentences, no redundancy, and efficient use of words to convey purpose and scope.
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 no output schema, the description would benefit from mentioning result format or typical fields. However, for a simple search tool, it provides the necessary context to decide usage.
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 has 100% coverage, but description adds meaning beyond schema by specifying case-insensitive matching against title and content, clarifying search semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search mkdshare.DEV documents by title and content'), resource, and scope, distinguishing it from siblings like list_documents and get_document.
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 context on the scope (owned/shared documents) but lacks explicit guidance on when to use vs. alternatives like list_documents for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_documentAInspect
Update an existing document you own. Omit any field to keep its current value.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Document slug | |
| title | No | New title | |
| content | No | New markdown content | |
| expires_at | No | ISO 8601 expiry datetime; omit to keep current | |
| visibility | No | New visibility level | |
| editor_emails | No | Comma-separated emails that can edit; pass empty string to clear | |
| allowed_domain | No | Domain allowed to view, e.g. company.com; required for domain_restricted | |
| allowed_emails | No | Comma-separated emails allowed to view; pass empty string to clear | |
| domain_can_edit | No | When true, all users in allowed_domain can edit (not just view) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ownership requirement and partial update semantics, but no annotations exist; fails to mention return value, error behavior, or reversibility.
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?
Single sentence with two clauses, no wasted words, purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, description adequately covers core behavior but omits return format and error/edge cases.
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 covers all 9 parameters with descriptions; the description adds value by clarifying that omitted fields retain current values, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'document' with an ownership constraint, distinguishing it from create_document and archive_document.
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?
Implicitly differentiates from sibling tools by specifying ownership and partial update behavior, but lacks explicit when-not or alternative tool guidance.
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.
Discussions
No comments yet. Be the first to start the discussion!