skill-audit-mcp
Server Details
Scan agent skills and MCP servers for malicious patterns before you load them
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- eltociear/skill-audit-mcp
- GitHub Stars
- 5
- Server Listing
- Skill Audit MCP
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 3.6/5 across 10 of 10 tools scored.
Individual tools have distinct names and descriptions, but the overall mix of security auditing and general data lookups creates confusion about the server's purpose, potentially leading an agent to select an inappropriate tool for the task.
Tool names are inconsistent in structure: some are single words (earthquakes, geocode), others are noun_noun (country_indicator, public_holidays), and only two follow a clear verb_noun pattern (audit_skill_text, audit_skill_url). No unified convention.
At 10 tools, the count is reasonable, but only 2 relate to the server's apparent core purpose (skill auditing). The remaining 8 are generic data lookups better suited to a separate server, making the set feel bloated and unfocused.
For the stated purpose of skill auditing, only text and URL scanning are covered, missing many expected features (e.g., dependency analysis, configuration review). The data tools are a random assortment, not a comprehensive collection for any domain.
Available Tools
10 toolsair_qualityAInspect
Current air quality for a place: PM2.5, PM10, ozone, NO2, SO2, CO and dust, plus the US and European AQI and the US AQI band ('Good', 'Unhealthy'). Takes a place name — no coordinates needed.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Place name, e.g. 'Tokyo' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output content but does not mention any behavioral traits such as rate limits, data freshness, error handling, or side effects. The statement about not requiring coordinates is more of a parameter clarification than behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the purpose and lists outputs in a structured way, making it easy to scan. 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 the tool's simplicity (one parameter, no nested objects, no output schema), the description is fairly complete. It enumerates the returned data (pollutants, AQI, bands). However, it could mention if there are any error conditions or fallback behavior for unrecognized place names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single 'location' parameter with an example. The description adds extra meaning by clarifying that only a place name is needed and coordinates are not required, which helps the agent understand the input format without trial and error.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving current air quality data for a place, listing specific pollutants (PM2.5, PM10, etc.) and indices (US/European AQI, band). It distinguishes from sibling tools by specifying the exact resource and output format, leaving no ambiguity.
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 context that the tool takes a place name and explicitly states that coordinates are not needed. However, it lacks explicit guidance on when to use or avoid this tool versus alternatives, and no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audit_skill_textAInspect
Scan text — an agent skill, MCP server source, or plugin — for malicious behaviour before loading it. 17 attack patterns / 60 regex signatures across 4 severity levels — credential exfiltration, download-and-execute, prompt injection, command execution, seed-phrase harvesting and more.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | File or snippet to scan |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists attack patterns and signatures, which indicates read-only scanning. However, it does not disclose return format, side effects (none expected), or whether results affect anything beyond the response.
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 two sentences, front-loading the primary action and scope, then efficiently listing details. No redundant or superfluous information.
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 complexity of a security scanner and no output schema, the description is missing crucial information about the return value (e.g., report format, severity indicators). It adequately describes input but not output, leaving the agent uncertain about how to use results.
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 covers the single parameter 'content' with a basic description. The tool description adds significant meaning by specifying what the scan looks for (17 patterns, 60 regexes, 4 severity levels, specific attack types), enriching the parameter's purpose beyond 'file or snippet to scan'.
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 scans text for malicious behavior, specifying the resources (agent skill, MCP server source, plugin). It naturally distinguishes from the sibling tool audit_skill_url by focusing on text content rather than URLs.
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 using this tool before loading code, providing clear context. However, it does not explicitly state when not to use it or mention alternatives for different scenarios, lacking exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audit_skill_urlAInspect
Fetch a URL and scan what it serves for malicious behaviour. 17 attack patterns / 60 regex signatures across 4 severity levels — credential exfiltration, download-and-execute, prompt injection, command execution, seed-phrase harvesting and more.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Raw file URL to fetch and scan |
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 scanning patterns and severity levels but does not mention whether the tool is read-only, potential side effects, rate limits, or error handling.
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 front-loads the action and lists key attack patterns concisely. It is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality but lacks information about return format, error handling, or limitations. Given no output schema, more detail on results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds no extra meaning beyond what the schema provides ('Raw file URL').
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 fetches a URL and scans for malicious behavior, listing specific attack patterns. It distinguishes from sibling 'read_url' (which likely just fetches content) and 'audit_skill_text' (which scans text).
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 the tool is for scanning URLs for malicious behavior but does not provide explicit guidance on when to use it versus alternatives, when not to use it, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_indicatorAInspect
World Bank time series for a country: gdp, gdp_per_capita, population, inflation, unemployment, life_expectancy, co2_per_capita or internet_users.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | 1-60 most recent years (default 5) | |
| country | Yes | ISO 2- or 3-letter country code | |
| indicator | No | Alias above, or a World Bank code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It reveals that the tool returns time series data for a country, but does not disclose behavioral traits such as data freshness, request limits, or the structure of the response (e.g., array of year-value pairs). The transparency is adequate but not comprehensive.
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, front-loaded sentence that immediately states the tool's purpose and lists key indicators. No superfluous words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no nested objects, no output schema), the description covers the essential purpose and parameter semantics. It could mention the output format (e.g., returns time series data points) to improve completeness, but it is already well-suited for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explicitly listing the indicator aliases, which are only referenced as 'Alias above' in the schema. This helps clarify valid indicator values beyond the schema's brief description.
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 provides World Bank time series for a country and lists specific indicators (gdp, gdp_per_capita, etc.), making its purpose explicit and distinct from siblings which cover other domains like weather, text audit, or geocoding.
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 retrieving economic indicators but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The context is clear but lacks direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earthquakesAInspect
Recent earthquakes from the USGS feed — worldwide, or within a radius of a named place. Returns magnitude, depth, tsunami flag and felt reports.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 1-30 days back (default 1) | |
| limit | No | 1-100 events (default 20) | |
| location | No | Centre on a place name | |
| radius_km | No | Radius around location (default 500) | |
| min_magnitude | No | Lower bound (default 4.5) |
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 mentions return fields but lacks details on destructive potential, authentication, rate limits, or side effects. The tool appears read-only, but this is not explicitly stated.
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, well-structured sentence that efficiently communicates purpose and key details without redundancy. Every part is informative.
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 simplicity of the tool (no output schema, no annotations, 5 parameters all described in schema), the description covers core functionality but omits details on response format, error handling, or pagination. It is minimally adequate but not 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 description coverage is 100%, so the baseline is 3. The description adds context about radius-based searching beyond the schema, but does not significantly enhance understanding of each parameter's meaning or constraints.
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 that the tool retrieves recent earthquakes from the USGS feed, specifying scope (worldwide or by radius) and return fields (magnitude, depth, tsunami flag, felt reports). This differentiates it from sibling tools like air_quality or geocode.
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 earthquake data search, hinting at location-based filtering via 'within a radius of a named place,' but provides no explicit guidance on when to use this tool versus alternatives, nor mentions any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevationBInspect
Ground elevation in metres for a place name.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Place name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the output. It does not mention API behavior, rate limits, or error conditions.
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 front-loaded sentence with no unnecessary words. It could be slightly more informative without sacrificing conciseness.
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 minimally adequate but lacks any behavioral or usage context that would help an agent use it 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 input schema has 100% parameter documentation coverage. The description adds no extra meaning beyond the schema's 'Place name' description, so baseline of 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 returns ground elevation in metres for a place name. It uses a specific verb and resource, and is distinct from sibling tools like geocode which returns coordinates.
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 no guidance on when to use this tool versus alternatives, nor any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geocodeBInspect
Resolve a place name to coordinates, country, admin region, timezone, elevation and population.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name to resolve | |
| count | No | 1-20 candidates (default 5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It lists the output fields (coordinates, country, etc.), which is helpful, but it lacks details on input format requirements (e.g., full vs. partial names), error behavior, rate limits, or data source reliability.
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 efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the key action and lists outputs.
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 complexity of geocoding and no output schema, the description is moderately complete. It lists expected outputs but does not explain output structure, error cases, or how to interpret multiple candidates. It lacks guidance on distinguishing from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'name' and 'count' both described. The tool description adds context that the output includes multiple fields, but it does not elaborate on how 'count' affects results or the expected format of 'name'. Baseline 3 is appropriate as the schema already explains the parameters.
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 'Resolve a place name to coordinates, country, admin region, timezone, elevation and population' clearly states the tool's function with specific verbs and outputs. It distinguishes from sibling tools like 'elevation' (which likely takes coordinates) and 'country_indicator', though it does not explicitly compare.
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 like 'elevation' or 'country_indicator'. The description gives no context for appropriate usage, prerequisites, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
public_holidaysAInspect
Public holidays for a country and year, with local names and a past/upcoming flag.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (defaults to current) | |
| country | Yes | ISO 2-letter country code, e.g. JP |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the output includes local names and a past/upcoming flag, but does not mention data source, update frequency, or limitations. No annotations provided, so description carries full burden.
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 that is clear, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description adequately specifies the returned data (local names, flag). No critical 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?
Schema covers 100% of parameters with descriptions; description adds no additional semantic meaning beyond restating country and year.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns public holidays with specific attributes (local names, flag) for a country and year, distinguishing it from sibling tools like air_quality or geo-related tools.
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?
Implied usage via context of sibling names, but no explicit when-to-use or alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlBInspect
Fetch a URL and return its main content as clean Markdown, boilerplate stripped.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to fetch |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose potential side effects, error handling, or limitations (e.g., rate limits, URL restrictions), only stating the core extraction behavior.
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?
A single sentence that front-loads the action, with 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?
Adequate for a simple one-parameter read tool, but missing details on URL scope (e.g., public vs. authenticated) and error responses.
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 param description 'Page to fetch', and the tool description adds negligible additional meaning, merely rephrasing the schema's intent.
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 ('Fetch a URL') and the resource, and distinguishes itself from sibling tools like 'web_search' by specifying the return of clean Markdown content.
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 on when to use this tool versus alternatives like 'web_search' or 'audit_skill_url', nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchAInspect
Search the live web and return ranked title/url/snippet results, through an automatic multi-engine failover chain.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | 1-25 (default 10) |
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 mentions the multi-engine failover chain, hinting at reliability, but does not disclose rate limits, authentication needs, or failure handling. For a simple search tool, this is adequate but not rich.
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, efficient sentence that front-loads the action and includes key details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description fully explains the output format (title/url/snippet) and the failover behavior. No missing information is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, such as query syntax or special characters. 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 verb 'Search', the resource 'the live web', and the outcome 'ranked title/url/snippet results'. It includes a unique feature ('automatic multi-engine failover chain') that distinguishes it from sibling tools, none of which are web search.
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 live web search but provides no explicit guidance on when or when not to use it, nor any mention of alternatives given the sibling tools. The context is clear but lacks exclusions or best practices.
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!
Your Connectors
Sign in to create a connector for this server.