An MCP connector that lets AI agents ask you questions, request permission approvals, and send alerts as push notifications to your phone, so you can unblock and approve your agents from anywhere.
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.8/5 across 5 of 5 tools scored.
Each tool has a completely distinct purpose: ask_user for interactive questions awaiting a reply, send_notification for one-way alerts, wait_for_answer for explicitly polling an existing question, cancel_question to retract a pending question, and propose_scope for a specific scope-ratification flow. The descriptions are so detailed that even edge cases (like send_notification embedding a question) are clearly separated from the primary ask_user workflow, leaving no ambiguity.
All five tool names follow a consistent verb_noun pattern in snake_case: ask_user, cancel_question, propose_scope, send_notification, wait_for_answer. The naming is predictable and makes the action and object of each tool immediately clear.
With exactly 5 tools, the set is well-scoped for a push-notification and user-approval server. Each tool fills a distinct role—asking, notifying, waiting, canceling, and scoping—without any redundant or unnecessary additions. This is an ideal size for the domain.
The tools cover the entire lifecycle of asynchronous user interaction: creating a question (ask_user), awaiting an answer (wait_for_answer), cancelling a stale question (cancel_question), sending a one-way notification (send_notification), and obtaining initial scope approval (propose_scope). There are no obvious dead ends or missing operations within the intended scope of the server.
ask_userAsk User a QuestionAInspectAsk the user a question as a push notification on their phone and block until they answer. Reach for this whenever you need the user's decision and they may be away from the terminal: approving a risky or irreversible step (deleting files, force pushing, spending money, sending external messages), picking between implementation options, or supplying missing input. The user answers from the lock screen or a decision page; you do not need a separate wait_for_answer call because this tool waits by default. Three question types: "confirm" (yes/no), "select" (2 to 6 fixed choices), "input" (free text). Timing: a single call blocks for at most 55 seconds, but the question itself stays answerable for 10 minutes. On { answered: true } the response carries value with the user's choice or text. On { answered: false, timedOut: true } keep the returned correlationId and call wait_for_answer with it, retrying up to 3 times with timeoutMs 55000, before falling back to asking in the terminal. Every response carries answerUrl, the signed-in dashboard page where this question is waiting. When you report that you are waiting, print that URL to the user so they can answer from a browser instead of hunting for it. Works from Claude Code, Codex, Cursor, Hermes, or any MCP client; no Claude subscription is required. SIDE EFFECT: sends a real push notification.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Deliver only to subscribers that have any of these tags. | |
| type | No | Question type: confirm renders yes/no buttons, select renders the options list, input renders a free-text field. | confirm |
| wait | No | true (default) blocks until the user answers or the timeout fires. Set false to return immediately with a pending correlationId and poll it yourself via wait_for_answer. | |
| action | No | The concrete operation about to happen, one line. Shown as the Action line. | |
| intent | No | The user's stated task (from their last prompt), one line. Shown as the Intent line so the user can see why the agent stopped. | |
| blocker | No | The single gating reason the agent stopped, one line. Shown as the Blocker line. | |
| context | No | One or two sentences about what the agent is working on, shown above the question so the user can decide without opening the terminal. | |
| options | No | The 2 to 6 choices for a select question. Required when type is "select", ignored otherwise. The answered value is the chosen option string. | |
| repoKey | No | Stable repository identity for the working directory, e.g. "github.com/acme/api". Lets an approval routing rule scoped to one repository avoid governing another. Optional; omit it and only workspace-wide routing rules apply. | |
| question | Yes | The question shown on the user's lock screen (max 500 chars). Phrase it so it is answerable at a glance; put background in context instead. | |
| toolName | No | The tool this approval is for (e.g. "Bash"), so the user can choose to always-allow it. | |
| agentName | No | Name of the agent asking, format "{Agent} - {project}" (e.g. "Claude Code - myproject"). Shown in the notification title so the user knows which session needs them. Falls back to the MCP client name if omitted. | |
| machineId | No | Stable machine id of the asking agent, so two machines never collapse into one session. | |
| scopePath | No | Set ONLY when this approval exists because the path falls outside the scope the user ratified via propose_scope. Approving then widens the run scope to include this exact path, so the user is not asked again for the same area. | |
| sessionId | No | Opaque per-session id of the asking agent, so parallel sessions are attributed separately. | |
| timeoutMs | No | How long this call blocks, in milliseconds (max 55000). Defaults to the site policy timeout. The question stays open for 10 minutes regardless, so a timeout here is not a refusal; follow up with wait_for_answer. | |
| actionBody | No | The diff (Edit/Write) or full command (Bash/apply_patch), secret-redacted and size-capped. Rendered as a collapsible detail block; never used as the push body. | |
| toolTarget | No | Compact target of the tool call (e.g. the command head "git push" for Bash, or a file extension like ".ts" for Edit/Write). Used to mine policy suggestions. | |
| callbackUrl | No | Webhook URL that receives a POST with the answer when the user responds, signed with the X-Pushary-Signature header. Useful when the agent process may exit before the answer arrives. | |
| externalIds | No | Deliver only to subscribers matching these external IDs. | |
| placeholder | No | Hint text shown inside the free-text field for input questions | |
| subscriberIds | No | Deliver only to these subscriber IDs. Omit all targeting fields to reach every connected device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing blocking behavior (55s block, 10-minute answerability), timing details, retry mechanics, and the explicit side effect: 'SIDE EFFECT: sends a real push notification.' This aligns with the readOnlyHint=false annotation and adds significant behavioral 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 long but front-loaded with the primary purpose and usage. It includes some redundancy with schema details (e.g., question type descriptions), but each sentence adds operational context such as timing, fallback, and side effects. Structurally it's a dense paragraph, not bulleted, but remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (22 parameters, no output schema), the description is exceptionally complete. It covers response shapes for both success and timeout, explains how to use the returned correlationId with wait_for_answer, describes retry limits, the answerUrl, and even instructs the agent to print the URL to the user. This is a fully self-contained operational guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all 22 parameters, so the baseline is 3. The description adds high-level behavioral guidance (e.g., question types, response shapes) but does not provide additional per-parameter semantics beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, unambiguous action: 'Ask the user a question as a push notification on their phone and block until they answer.' It clearly distinguishes itself from the sibling tool wait_for_answer by stating 'you do not need a separate wait_for_answer call because this tool waits by default.'
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: 'Reach for this whenever you need the user's decision and they may be away from the terminal,' followed by concrete scenarios. It also points to the alternative wait_for_answer in timeout handling, and mentions falling back to asking in the terminal, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_questionCancel Pending QuestionARetract a pending question so it can no longer be answered. Use this when a question became irrelevant before the user replied: the agent found the answer itself, the task was aborted, or a newer question supersedes it. Cancelling prevents a stale approval from arriving later and acting on work that has moved on. Only affects questions that are still pending; questions expire on their own 10 minutes after creation. Returns { cancelled: true } when a pending question was removed, { cancelled: false } when it was already answered, expired, or unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| correlationId | Yes | The correlationId of the pending question to cancel, as returned by ask_user or send_notification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond annotations: it affects only pending questions, questions expire on their own, and it specifies return values for different outcomes (cancelled true/false). This adds meaningful context to the idempotentHint and readOnlyHint annotations, and it does not contradict any 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?
The description is four sentences with no redundant filler. Each sentence adds value: purpose, usage scenarios, behavioral constraints, and return values. It is front-loaded with the core action and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter, no output schema, but nuanced behavior), the description fully covers when to use, what happens in edge cases, and what the return value means. It is complete for an agent to invoke correctly without additional context.
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 schema description already explains correlationId as 'the correlationId of the pending question to cancel, as returned by ask_user or send_notification.' The tool description does not add additional parameter semantics beyond that, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Retract a pending question so it can no longer be answered,' using a specific verb and resource. This clearly distinguishes it from sibling tools like ask_user (which creates questions) and send_notification (which sends notifications), and it explains the outcome of the action.
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 the tool: 'Use this when a question became irrelevant before the user replied: the agent found the answer itself, the task was aborted, or a newer question supersedes it.' It also explains the consequence of cancellation (prevents stale approval) and notes edge cases (only affects pending questions, self-expiry after 10 minutes), providing clear guidance beyond mere naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propose_scopePropose Run ScopeAInspectPropose what this run will touch and block until the user ratifies it. Call ONCE at the start of a multi-step run, before doing work. The user sees the paths you intend to change, the areas you promise to leave alone, and your definition of done, and approves the whole thing in one tap. After that, editing a file outside the agreed scope stops being auto-approvable: it becomes a separate "wants to widen scope" question instead of a silent approval, so you are asked once about the boundary rather than repeatedly about each file. Use glob syntax ("src/", "/*.test.ts"). Shell commands are NOT scoped here, they stay governed by the permission policy. Scope lives for this session only and is never inherited by another run. Returns { ratified, answered, value }; ratified:true means the contract is live. If the user declines, do not proceed as if they had agreed, ask them what scope they want. SIDE EFFECT: sends a real push notification.
| Name | Required | Description | Default |
|---|---|---|---|
| doneWhen | Yes | What "finished" means for this run, one or two lines. Carried for the human to judge against; never enforced automatically. | |
| agentName | No | Name of the agent asking, format "{Agent} - {project}". | |
| machineId | No | Stable machine id, so two machines never collapse into one session. | |
| sessionId | Yes | Your per-session id. Required: a scope with no session cannot be enforced, and must never leak into another run. | |
| timeoutMs | No | How long this call blocks, in milliseconds (max 55000). | |
| allowedPaths | No | Globs you intend to change, e.g. ["src/**", "docs/*.md"]. Omit or leave empty to propose no path restriction, which the user is told plainly. | |
| offLimitsPaths | No | Globs you promise not to touch, e.g. ["**/.env*", "infra/**"]. These win wherever they overlap allowedPaths. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which note non-read-only, non-idempotent), the description discloses critical behaviors: blocking until ratification, the session-scoped nature, the change in auto-approval for out-of-scope edits, the side effect of a push notification, and the return value shape. This is rich behavioral context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, with each sentence earning its place. It front-loads the core purpose and then systematically covers call timing, user experience, scope enforcement, exclusions, session behavior, return value, decline handling, and side effects. 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?
Given the tool's complexity, the description is complete: it explains when to call it, what it does, how it affects subsequent actions, session lifetime, what it does not cover, the return structure, and the side effect. There is no output schema, so the description explicitly describes the return object. This is sufficient for correct selection and 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds only minimal parameter-related guidance (e.g., 'Use glob syntax'), but the schema already includes examples for allowedPaths and offLimitsPaths. The description does not significantly enhance parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Propose what this run will touch and block until the user ratifies it.' This clearly states the tool's action and distinguishes it from sibling tools like ask_user or wait_for_answer by focusing on proposing a run scope and obtaining ratification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call ONCE at the start of a multi-step run, before doing work.' It also provides clear exclusions: 'Shell commands are NOT scoped here' and 'Scope lives for this session only,' which prevent misuse. The handling of user decline is also specified, covering a common edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_notificationSend Push NotificationAInspectSend a one-way push notification to the user's phone and browser. Nothing is awaited; use ask_user instead when you need an answer back. Reach for this when a long-running task finishes and the user asked to be told, when the agent hits an error it cannot resolve on its own, or for any "notify me when my agent needs me" moment while the user is away from the terminal. By default the notification reaches every device connected to the site; narrow delivery with subscriberIds, externalIds, or tags. The optional context object turns the tap-through into a rich detail page (summary, bullet details, changed files, error info, next steps), and context.askQuestion embeds a decision prompt on that page, returning a linkedCorrelationId you can poll with wait_for_answer. Returns per-channel delivery counts for web and mobile, plus a warning when zero devices are connected. Works from Claude Code, Codex, Cursor, Hermes, or any MCP client; no Claude subscription is required. SIDE EFFECT: delivers real notifications to real devices immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL opened when the user taps the notification. Ignored if context is provided, because a context detail page URL is generated automatically. | |
| body | Yes | Notification body text (max 500 chars). One or two sentences the user can act on without opening anything. | |
| tags | No | Deliver only to subscribers that have any of these tags. | |
| title | Yes | Notification title shown on the lock screen (max 100 chars). Lead with the outcome, e.g. "Build finished" or "Migration failed". | |
| context | No | Structured context rendered as a rich detail page when the user taps the notification. Strongly recommended for task_complete and error notifications so the user can act from their phone. | |
| iconUrl | No | URL of the notification icon image | |
| imageUrl | No | URL of a large image shown in the notification | |
| agentName | No | Name of the agent sending this notification, format "{Agent} - {project}" (e.g. "Claude Code - myproject"). Shown in the notification so the user knows which session is talking. Falls back to the MCP client name if omitted. | |
| machineId | No | Stable machine id of the sending agent, so two machines never collapse into one session. | |
| sessionId | No | Opaque per-session id of the sending agent, so parallel sessions are attributed separately in the activity feed. | |
| externalIds | No | Deliver only to subscribers matching these external IDs. | |
| subscriberIds | No | Deliver only to these subscriber IDs. Omit all targeting fields to reach every connected device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide non-read-only and open-world hints, but the description adds crucial context: 'Nothing is awaited' and 'SIDE EFFECT: delivers real notifications to real devices immediately.' It also discloses default delivery to all connected devices, per-channel return counts, and warnings for zero devices, going well beyond annotation flags.
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 lengthy but information-dense, front-loading purpose and usage before diving into targeting, context, return values, client compatibility, and side effects. Every sentence earns its place, especially for a tool with 12 parameters and nested objects.
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?
Covers all essential aspects: purpose, when to use, delivery targeting, context rendering, askQuestion flow, return counts/warnings, client compatibility, and explicit side effects. Given no output schema, describing return values is critical. This is a model description for a complex notification 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 has 100% parameter description coverage, so baseline is 3. The description adds high-level semantic integration: explains how subscriberIds/externalIds/tags narrow delivery, and how the context object turns tap-through into a rich detail page with askQuestion returning a linkedCorrelationId for wait_for_answer. This adds meaning beyond individual schema entries.
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 'Send a one-way push notification to the user's phone and browser' with a specific verb and resource. It distinguishes from siblings by explicitly naming ask_user as the alternative when an answer is needed, and frames the tool as one-way and fire-and-forget.
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 when-to-use scenarios: long-running task completion, unresolvable errors, and 'notify me when my agent needs me' moments while the user is away. Also states when not to use (use ask_user for two-way answers) and points to wait_for_answer for polling askQuestion results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_answerWait for User AnswerAPoll for the user's answer to a previously created question. Use it in three cases: after ask_user with wait set to false, after an ask_user call that returned timedOut, or with the linkedCorrelationId from a send_notification that embedded an askQuestion. Each call blocks until the answer arrives or timeoutMs expires (default 30 seconds, max 55). Questions live for 10 minutes in Redis, so when a call comes back { answered: false }, retry with the same correlationId up to 3 times with timeoutMs 55000 to give the user time to reach their phone; only then treat the question as unanswered and fall back to asking in the terminal. Returns { answered: true, value } once the user responds, where value is "yes"/"no" for confirm, the chosen option for select, or the typed text for input.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutMs | No | How long this call blocks, in milliseconds (default 30000, max 55000). Retry with the same correlationId to keep waiting; the question expires 10 minutes after it was asked. | |
| correlationId | Yes | The correlationId from an earlier ask_user response, or the linkedCorrelationId from a send_notification with an embedded askQuestion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations. It discloses the blocking/polling nature, default and max timeoutMs, the 10-minute question expiry in Redis, retry logic, and the exact return shape ({ answered: true/false }). This complements the readOnlyHint and idempotentHint fields with operational context. 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 dense but every sentence carries necessary information. It front-loads the purpose, then logically moves through use cases, timing, retry, and return format. No filler or repetition—each sentence earns its place in a compact yet complete paragraph.
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 no output schema, the description fully explains the return value and its variants. It also covers the unanswered case (answered: false), the retry count, timeout behavior, and fallback. Given the tool's moderate complexity and the absence of an output schema, the description is exceptionally complete and self-sufficient.
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?
Even though the schema provides 100% parameter descriptions, the tool description enriches both parameters. It clarifies timeoutMs's default (30000), max (55000), and retry semantics, and explains that correlationId comes from an earlier ask_user response or linkedCorrelationId from send_notification. This goes well beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Poll for the user's answer to a previously created question." It goes beyond a generic statement by enumerating the exact trigger scenarios (ask_user with wait=false, timedOut, or linkedCorrelationId from send_notification), clearly distinguishing it from siblings like ask_user and send_notification.
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?
Usage guidance is explicit and actionable. It lists the three concrete cases when to use the tool, gives retry parameters (up to 3 times, timeoutMs 55000), explains the Redis 10-minute expiration, and specifies the fallback behavior to asking in the terminal. This leaves no ambiguity about when to invoke this tool versus alternatives.
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!
