mcp-server
Server Details
Scan any URL for 20 SEO checks; get a 0-100 score with prioritized fix recommendations.
- 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.7/5 across 8 of 8 tools scored.
Each tool addresses a distinct stage of the SEO scanning workflow (submit, poll status, get results, purchase, poll purchase, get remediation, look up past scans, help). No two tools have overlapping purposes.
Most tools follow a clear verb_noun pattern (e.g., get_scan_results, submit_scan). One exception is 'how_to_use', which is a phrase rather than verb_noun, and 'find_my_reports' includes an informal 'my'. Overall consistent.
8 tools is well-scoped for the server's purpose—covering scan submission, status polling, result retrieval, purchase flow, and user lookup. Each tool earns its place.
The tool surface covers the full user journey from scanning to remediation, plus lookups. Minor gaps: no tool to cancel a scan or list all scans beyond the email-based lookup, but these are not essential for the core workflow.
Available Tools
8 toolsfind_my_reportsFind My SEO Scans / Reports by EmailARead-onlyIdempotentInspect
Look up a user's recent SEO scans by the email they used — for RETURNING users who don't have a scan_id handy (scanned/purchased earlier or on the website). In a fresh session where the user has no scan_id, START HERE: ask the user for that email, then call this. Returns up to 10 recent scans as {scan_id, url, scanned_at, paid, runbook_ready}. Then use the scan_id with get_remediation_plan (if paid+runbook_ready) or purchase_report (if not paid).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address the user used when scanning or purchasing. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds value by specifying the return format (up to 10 recent scans with fields {scan_id, url, scanned_at, paid, runbook_ready}), which is not in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: starts with purpose, then usage guidance, then result format, then next steps. It is concise with minimal redundancy, though slightly longer than necessary. Could be broken into clearer sections, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return values and how to use them. Given the tool's simplicity (one parameter, no nested objects), it covers all necessary context: input, output, and integration with sibling tools. 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?
The only parameter is 'email' with 100% schema description coverage (format). The description adds context: 'the email they used when scanning or purchasing,' clarifying the purpose and usage beyond the schema. Since coverage is high, baseline is 3, but the extra context warrants a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it looks up a user's recent SEO scans by email, targeting returning users without a scan_id. It specifies the verb 'look up' and resource 'SEO scans/reports,' distinguishing from siblings like get_scan_results which likely requires a scan_id.
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 ('for RETURNING users who don't have a scan_id handy... In a fresh session... START HERE') and provides a clear workflow after retrieval (use scan_id with get_remediation_plan or purchase_report). It also implies when not to use (if user has scan_id, skip this).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_purchase_statusCheck SEO Report Purchase Status (lightweight poll)ARead-onlyIdempotentInspect
Lightweight poll for whether a scan's paid remediation report is ready, WITHOUT downloading the full plan. Use this in the wait loop after purchase_report: call about every 15 seconds until both paid and runbook_ready are true, then call get_remediation_plan ONCE to fetch and execute the plan. paid=false => the user hasn't completed checkout yet; paid=true, runbook_ready=false => payment landed and the plan is still being generated (retry shortly).
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from submit_scan / purchase_report. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: it is a lightweight poll that does not download, and explains the possible states (paid=false, paid=true+runbook_ready=false). No contradictions.
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, front-loaded with purpose, then usage details, then state explanations. Every sentence adds value without redundancy. 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?
The description provides sufficient context for correct usage in the wait loop, including state machine logic. No output schema exists, so the return format is not explained, but the purpose is well-covered. Could optionally mention response fields, but not essential.
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 only parameter (scan_id) has 100% schema coverage with a description. The tool description adds minimal additional meaning beyond referencing context like 'from submit_scan / purchase_report', but this is already implied by the schema description. 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 is a lightweight poll to check if a paid remediation report is ready without downloading the full plan. It distinguishes itself from siblings like get_remediation_plan and get_scan_status.
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 describes when to use (in a wait loop after purchase_report), polling frequency (every 15 seconds), exit conditions (both paid and runbook_ready true), and what to call next (get_remediation_plan once). Also implies when not to use (not for downloading).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_remediation_planGet the SEO Remediation Plan (Claude Code runbook)ARead-onlyIdempotentInspect
Retrieve the full paid remediation plan for a purchased scan, as a Markdown runbook built for an AI coding agent to execute. Save the returned markdown to a file named by filename (e.g. seo-remediation-plan.md) in the user's project, then work through it top to bottom. It lists each issue in priority order with the exact fix, copy-ready replacement strings, explicit '❓ ASK THE OWNER' stops where you must get the owner's input (never invent brand names, keywords, phone numbers, or addresses), and a verification step (re-run submit_scan after each fix to confirm it passes). If the scan has NOT been purchased, returns paid=false with guidance to call purchase_report first. If the plan is still generating, returns status='generating' — call again in ~30 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID that was purchased via purchase_report. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safety. The description adds behavioral details: returns markdown runbook, may return paid=false or status='generating', includes warnings about not inventing data, and mentions verification steps. 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 relatively long but well-structured and informative. It front-loads the main purpose and then provides step-by-step guidance. A slightly more concise presentation could improve readability without losing value.
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?
No output schema exists, but the description thoroughly explains the response format: markdown content, priority-ordered issues, exact fixes, 'ASK THE OWNER' stops, verification steps. It also covers edge cases (unpurchased, generating). Complete for a single-parameter retrieval tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the one parameter (scan_id). The description does not add new information about parameter 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 specifies the tool's purpose: 'Retrieve the full paid remediation plan for a purchased scan.' It identifies the resource (remediation plan) and the action (retrieve). It distinguishes from sibling tools like submit_scan and purchase_report by including conditions for calling those alternatives.
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 usage guidelines: use after a scan is purchased, if not purchased call purchase_report, if still generating call again in ~30 seconds. It also gives detailed instructions on what to do with the output (save to file, work through top to bottom).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scan_resultsGet SEO Scan ResultsARead-onlyIdempotentInspect
Fetch the full structured scan findings. Free tier returns the top 5 issues by severity (failed > warned > passed); paid customers see all checks. When summarizing results to the user, ALWAYS: (1) report the score and counts of failed/warned/passed checks, (2) surface each returned check's remediation text verbatim, (2b) for sophisticated users, mention each check's when_doesnt_apply context so they can dismiss findings that don't apply to their site type (e.g., link aggregators legitimately omit a visible H1; empty string means the rule is universally required), (2c) note site_type ('marketing' or 'not_marketing') and score_rubric ('standard' or 'non_marketing_weighted') so the user understands how the score was computed; non-marketing sites get contextual checks at half-weight, so a forum-style site won't be unfairly penalized for missing landing-page features, (3) if truncated is true, surface truncated_message so the user knows the API capped the output, (4) include upgrade.call_to_action and upgrade.checkout_url verbatim so the user can one-click into Stripe checkout for the $8.99 detailed fix guide. If upgrade.already_purchased is true, instead direct the user to upgrade.report_url to re-download.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from a prior submit_scan call. The scan must be in 'complete' status. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and idempotentHint=true. The description adds critical behavioral context: free tier truncation to top 5 issues, the 'truncated' flag and message, upgrade flow (call_to_action, checkout_url, already_purchased behavior), and special weighting logic for non-marketing sites. This far exceeds what annotations 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 lengthy but every sentence serves a purpose. The core action is front-loaded ('Fetch the full structured scan findings.') followed by tier differences and a detailed usage checklist. While a bit verbose, the complexity of the return types and conditional logic justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description comprehensively documents all fields returned (score, counts, checks, remediation, when_doesnt_apply, site_type, score_rubric, truncated, truncated_message, upgrade objects). It also explains edge cases like non-marketing site weighting, making the tool fully self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter, scan_id, with a clear description). The description adds that the scan must be in 'complete' status, which is a helpful prerequisite not found in the schema. No further parameter information is 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?
The description starts with a clear verb+resource: 'Fetch the full structured scan findings.' It specifies the tool's unique role (retrieving detailed results) and implicitly distinguishes it from siblings like get_scan_status (which only checks scan status) and submit_scan (which initiates scans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context: the scan must be complete ('Scan ID from a prior submit_scan call'). It also details tier differences (free vs. paid) and gives a comprehensive checklist for summarizing results to the user, effectively acting as usage instructions for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scan_statusGet SEO Scan StatusARead-onlyIdempotentInspect
Check whether a queued scan has completed. Lightweight polling endpoint — call every 3-5 seconds with the scan_id returned by submit_scan. Scans typically complete in 5-15 seconds. When status is 'complete', call get_scan_results for the structured findings. When 'failed', surface the error field to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from a prior submit_scan call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly, idempotent, non-destructive. The description adds that it is a 'lightweight polling endpoint' and provides typical completion time, which are useful behavioral details 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?
Three concise sentences, no redundancy. Front-loaded with purpose, then usage, then next steps. Every sentence adds value.
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 a simple 1-param tool with no output schema, the description covers the polling pattern, typical timing, and branching logic (success vs. failure). Annotations fully cover safety. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single param scan_id described as 'Scan ID from a prior submit_scan call.' The description reinforces this by stating 'returned by submit_scan,' adding clarity on provenance.
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 'Check whether a queued scan has completed,' clearly stating the verb (check) and resource (scan status). It distinguishes from sibling tool get_scan_results by noting that after completion, the user should call that tool for findings.
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 advises calling every 3-5 seconds with the scan_id, gives typical completion time (5-15 seconds), and instructs what to do on both 'complete' and 'failed' statuses, citing sibling tool get_scan_results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_useHow to Use Abby SEOARead-onlyIdempotentInspect
Returns a plain-English usage guide for this server — example requests, what it asks the user for, and the available tools. Call this if the user asks how to use Abby SEO, or to orient yourself before starting. (Same content as the 'getting_started' prompt, exposed as a tool for clients that don't surface MCP prompts.) Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, non-destructive. Description adds that it returns plain text and is the same as the getting_started prompt. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential: what it returns, when to call, relationship to prompt. Front-loaded with the key action. 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 help tool with no parameters and rich annotations, the description covers return content, usage, and context. 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. Description states 'Takes no arguments.' which is sufficient. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'returns a plain-English usage guide' with specific content. It distinguishes itself from sibling action tools like 'submit_scan' or 'purchase_report' by being a help 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?
Explicitly says to call it 'if the user asks how to use Abby SEO, or to orient yourself before starting.' No alternatives needed as it's a unique help tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_reportPurchase the Full SEO Fix ReportAInspect
Start a purchase of the full paid SEO remediation report for a COMPLETE scan ($8.99). Returns a Stripe checkout_url — payment CANNOT be collected through this tool. AUTONOMOUS FLOW: after calling this, do NOT stop and wait for a new user instruction. (1) Show the user checkout_url and ask them to complete payment in their browser. (2) Then poll get_purchase_status with the same scan_id about every 15 seconds: while paid is false the user hasn't finished — keep waiting (poll for up to a few minutes). (3) Once paid and runbook_ready are both true, call get_remediation_plan once, save the returned markdown to the file it names, and begin the remediation automatically — no further prompting needed. If this call returns already_purchased=true, skip the wait and go straight to get_remediation_plan.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from submit_scan. The scan must be 'complete'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that payment cannot be collected through the tool, behavior is non-blocking (returns URL), and describes the polling workflow. Annotations indicate openWorldHint and mutation, but description adds crucial context about external payment dependency and conditional retry logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long due to complexity but well-structured with numbered autonomous flow steps. Every sentence serves a purpose; 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 output schema, description fully explains return values (checkout_url, already_purchased) and the complete workflow. It leaves no ambiguity about what happens before, during, and after the call.
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 already covers scan_id with 100% description coverage, so baseline is 3. The description adds value by stating that the scan must be 'complete' and originating from submit_scan, providing necessary precondition context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a purchase for the SEO remediation report at $8.99, returning a Stripe checkout_url. It distinguishes itself from siblings like get_purchase_status and get_remediation_plan by specifying its unique role in the purchase flow.
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 step-by-step autonomous flow instructions: show checkout_url, poll get_purchase_status, wait for paid and runbook_ready, then call get_remediation_plan. Also covers the edge case of already_purchased=true, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_scanSubmit SEO ScanADestructiveInspect
Queue an SEO scan of a website URL. Returns a scan_id to poll. You MUST collect the user's email address before calling this tool — the API rejects submissions without one because results are emailed to the user. After this tool returns, call get_scan_status every few seconds with the returned scan_id until status is 'complete', then call get_scan_results for the findings.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the page to scan (https://example.com). http:// or https:// scheme will be added if missing. | |
| Yes | REQUIRED. The user's email address. Scan results will be sent here. ASK THE USER for this if you don't already know it — do not invent a placeholder. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. Description adds context: results are emailed, API rejects without email, and polling pattern. No contradictions.
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, each essential. Front-loaded with action, then workflow steps. 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 tool with no output schema, description explains return value (scan_id) and provides complete post-invocation workflow. Sibling tools are referenced, making context 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 covers both parameters with descriptions. Description adds nuance: URL scheme will be added if missing, and email must be explicitly asked from user, not invented.
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 queues an SEO scan and returns a scan_id. It distinguishes from siblings by mentioning polling and result retrieval, with specific sibling names for follow-up steps.
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 collect user's email before calling, outlines post-call workflow with get_scan_status and get_scan_results, and explains why email is required.
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!