MockHero
Server Details
Generate realistic relational test data — 156 field types, 22 locales, JSON/CSV/SQL, free previews.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- dinosaur24/mockhero
- GitHub Stars
- 1
- Server Listing
- mockhero
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.1/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Most tools have clearly distinct purposes, but `generate_from_template` and `generate_test_data` could be confused if an agent does not read descriptions carefully, as both produce test data. However, the descriptions adequately differentiate them by input type (template vs. schema/prompt).
All tool names follow a consistent `verb_noun` pattern with underscores (e.g., `create_agent_checkout`, `list_templates`). No mixing of styles, making the naming predictable.
With 9 tools, the server is well-scoped for its purpose—covering checkout, estimation, schema detection, data generation, and listing utilities. No tool feels redundant or missing.
The tool surface covers the full workflow from schema detection to data generation and payment handling. Missing features like schema update or key management are minor and do not severely impact core functionality.
Available Tools
9 toolscheck_agent_checkout_statusARead-onlyInspect
Poll a Polar checkout created by create_agent_checkout using the returned claim_token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | claim_token returned by create_agent_checkout. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds only 'Poll' and the token dependency, which is already in the schema. It does not disclose any additional behavioral traits like polling frequency, timeouts, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the purpose. No extraneous information, every word is necessary.
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 polling tool with one parameter, annotations, and an output schema, the description provides adequate context. It could be slightly improved by hinting at polling behavior, but it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the token parameter already documented. The description essentially repeats the schema description, adding no new meaning. 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 states a clear verb ('Poll') and resource ('Polar checkout'), and explicitly links it to the sibling tool create_agent_checkout via the claim_token. This distinguishes it from other siblings like claim_agent_api_key or create_agent_checkout.
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 after create_agent_checkout by referencing the claim_token. It provides clear context but does not explicitly state when not to use it or name alternatives, though sibling names imply the different roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_agent_api_keyAInspect
Claim the MockHero API key after Polar marks the loginless agent checkout as paid. The key is returned once.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | claim_token returned by create_agent_checkout. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait that the key is returned only once, which is not conveyed by the annotations. This helps the agent understand the non-reentrant nature. No contradictions 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 two sentences with no extraneous information. It is front-loaded with the core purpose and efficiently conveys the key constraints.
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, output schema present), the description adequately covers the purpose, precondition, and one-time behavior. It could mention the consequence of calling again, but that is minor.
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 100% of parameter descriptions. The description does not add further parameter details beyond what the schema already provides, so baseline score 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 uses a specific verb ('Claim') and resource ('MockHero API key'), clearly states the precondition (after Polar marks checkout as paid), and distinguishes from sibling tools like create_agent_checkout and check_agent_checkout_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?
The description clearly indicates when to use the tool (after payment is marked) and that it is a one-time operation. It does not explicitly state when not to use or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_agent_checkoutAInspect
Create a loginless Polar Checkout URL for MockHero's metered agent plan. Polar is the Merchant of Record for checkout, tax collection, and remittance. The card payment step needs a human: present the returned url to your operator together with the estimate_agent_usage cost, keep the claim_token private, then poll check_agent_checkout_status and call claim_agent_api_key once paid.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Billing email for the agent or the agent operator. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that Polar is the Merchant of Record and that card payment needs human interaction. Aligns with annotations (readOnlyHint=false, openWorldHint=true) and adds context about the process beyond structured fields.
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 with no wasted words. Front-loaded with the primary purpose and efficiently covers after-usage steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and that an output schema exists (though not shown), the description adequately covers the tool's role and the workflow, making it complete 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% with a clear description for the single parameter (email). The tool description does not add new semantic information beyond the schema, so baseline score 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 verb 'create' and the resource 'Polar Checkout URL' with specific context (MockHero's metered agent plan). It distinguishes from sibling tools like check_agent_checkout_status and claim_agent_api_key by describing the overall 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?
Explicitly provides when to use (to start checkout), what to do with the returned URL, and subsequent steps (poll and claim). Also notes that card payment requires a human operator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_schemaARead-onlyInspect
Convert SQL CREATE TABLE statements or one sample JSON object into a MockHero schema that can be passed to generate_test_data.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | No | SQL CREATE TABLE statement or statements. | |
| sample_json | No | Single example JSON object to infer fields from. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that it converts inputs to a schema, which is the core functionality. No additional behavioral details are provided beyond what annotations cover.
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 is efficient and front-loaded with the tool's purpose and output context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description is sufficiently complete. It mentions the connection to generate_test_data, which provides context, but could briefly note that multiple SQL statements are supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions are fully present. The description adds no extra meaning to the parameters beyond the schema definitions.
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 converts SQL CREATE TABLE statements or a sample JSON object into a MockHero schema, specifying the exact input types and the tool's output destination (generate_test_data).
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 ties the tool to generating test data, which clarifies its context among siblings like generate_from_template. However, it does not mention when to choose this over other schema-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_agent_usageBInspect
Estimate MockHero agent-plan cost before generating data. No login or API key is required; include an API key only when you want the estimate to use actual daily usage.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible output. | |
| scale | No | Multiplier for template record counts. | |
| format | No | json | |
| locale | No | Default locale such as en, de, fr, es, or ja. | |
| prompt | No | Plain-English data request. Example: 50 users and 200 orders linked to them. | |
| tables | No | ||
| api_key | No | Optional MockHero API key for no-auth MCP clients. Prefer the Authorization header when the client supports it. | |
| template | No | ||
| sql_dialect | No | ||
| daily_used_before | No | Optional assumption when no API key is supplied. | |
| estimated_records | No | Required for prompt estimates because this tool does not run prompt-to-schema conversion. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavioral traits: no login or API key is required, and the tool does not run prompt-to-schema conversion (noted in schema for estimated_records). Annotations indicate non-read-only, but the description adds useful context about authentication and limitations.
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 main description is concise, consisting of one clear sentence that states the purpose and key authentication behavior. It is front-loaded with the tool's primary function, though additional parameter notes are embedded in the schema.
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 presence of an output schema and 11 parameters with 64% schema coverage, the description provides necessary context but does not detail the estimate output or cover all parameters comprehensively. The limitation about prompt-to-schema conversion is noted, contributing to 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?
With 64% schema description coverage, the description adds value by clarifying the api_key parameter's optionality and purpose for using actual daily usage. Other parameters rely on schema descriptions, so the description provides moderate additional meaning.
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 estimates cost before generating data, specifying the verb 'estimate' and resource 'MockHero agent-plan cost'. It distinguishes from sibling tools like generate_from_template and generate_test_data by focusing on estimation rather than generation.
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 guidance on when to include an API key for actual daily usage, implying this tool is for cost estimation prior to data generation. However, it does not explicitly state when to use this tool over alternatives or exclude scenarios, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_from_templateAInspect
Generate realistic test data from a pre-built MockHero template: ecommerce, blog, saas, or social. Small template previews up to 100 records can run free; larger or production usage requires a MockHero API key.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| scale | No | ||
| format | No | json | |
| locale | No | ||
| api_key | No | Optional MockHero API key for no-auth MCP clients. Prefer the Authorization header when the client supports it. | |
| template | Yes | ||
| sql_dialect | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate not read-only, not idempotent, not destructive. The description adds context about size limitations and API key requirements, enhancing transparency. No contradictions 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?
Two sentences, front-loaded with the core purpose. Every sentence adds value: the first defines the action, the second provides usage constraints. 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 has 7 parameters and an output schema, the description covers the main functionality and a key constraint (free tier limit). However, it omits explanations for most parameters, leaving uncertainty about how to use features like seed, scale, format, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only implicitly adds value for the 'template' parameter by listing options, but the schema already defines an enum. With only 14% schema description coverage, the description fails to explain critical parameters like seed, scale, format, locale, and sql_dialect, leaving a significant gap.
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 'generate' and resource 'test data from a pre-built MockHero template', enumerating the four specific templates: ecommerce, blog, saas, or social. This distinguishes it from the sibling 'generate_test_data' which likely has a different scope.
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 guidance on when to use the free tier (previews up to 100 records) and when an API key is needed (larger or production usage). However, it does not explicitly contrast with the sibling 'generate_test_data' or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_test_dataAInspect
Generate realistic JSON, CSV, or SQL test data from structured tables or a plain-English prompt. Explicit table schemas up to 100 records can run free as a proof-of-work preview; plain-English prompt generation, larger requests, and production usage require a MockHero API key.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible output. | |
| format | No | json | |
| locale | No | Default locale such as en, de, fr, es, or ja. | |
| prompt | No | Plain-English data request. Example: 50 users and 200 orders linked to them. | |
| tables | No | ||
| api_key | No | Optional MockHero API key for no-auth MCP clients. Prefer the Authorization header when the client supports it. | |
| sql_dialect | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Expands on annotations (readOnlyHint=false, openWorldHint=true, etc.) by disclosing free tier limits and API key authentication. Describes behavior beyond schema: preview vs production, and auth options. No contradictions 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?
Two sentences, front-loading purpose and constraints. Every word earns its place; no redundant 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 output schema exists, description covers two modes and their constraints. Missing explicit error behavior if limits exceeded, but completeness is adequate for agent decision-making.
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 57%, and description adds value by explaining free record limit for 'tables' and that 'prompt' requires API key. This provides context not in schema (e.g., 'tables' maximum 100 records free). Baseline 3 raised due to additional operational 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?
Description clearly states it generates realistic test data from tables or plain-English prompt, listing formats (JSON, CSV, SQL). It distinguishes from siblings like 'generate_from_template' by specifying it works with structured tables or prompts, not templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: for generating test data from explicit tables or prompts. Mentions free preview for tables up to 100 records and API key requirement for larger/production use. However, does not explicitly state when not to use or compare with alternatives beyond implicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_field_typesARead-onlyInspect
List MockHero field types, descriptions, parameters, and examples before building a schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds value by specifying exactly what the tool returns (field types, descriptions, parameters, examples), which is sufficient behavioral context for a simple read-only list.
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 verb and object, includes a valuable context clause ('before building a schema'), and contains no unnecessary words. It is perfectly concise.
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 (no parameters, output schema exists) and the rich annotations, the description fully informs an agent about what this tool does and when to use it. No additional details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% empty), so the description cannot add parameter-level meaning. Baseline for 0 parameters is 4, and the description does not need to compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'MockHero field types', along with the specific content (descriptions, parameters, examples) and context ('before building a schema'). It is distinct from sibling tools like 'detect_schema' and 'list_templates', which focus on different aspects.
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 the usage context ('before building a schema'), giving a strong clue about when to invoke it. However, it does not mention alternatives or when not to use it, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesARead-onlyInspect
List MockHero's pre-built schema templates for ecommerce, blog, SaaS, and social apps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the context of template categories, which is useful but does not provide additional behavioral traits beyond what annotations already convey (readOnlyHint=true). No mention of caching, dynamism, or other behaviors.
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 focused sentence that front-loads the purpose. Every word contributes meaning, and there is no redundant 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 no parameters, sufficient annotations, and an output schema, the description is adequately complete. It covers what the tool does and what it returns, though it could mention that it returns all available templates without filtering.
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?
With zero parameters, the baseline is 4. The description adds value by naming the categories of templates returned, which helps the agent understand output scope without needing parameter details.
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 explicitly states the action ('List'), the resource ('pre-built schema templates'), and the specific categories (ecommerce, blog, SaaS, social apps), making it clear and distinct from sibling tools like generate_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the name implies browsing templates before generation, no exclusions or direct comparisons are given.
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.