Conversor IAE-CNAE
Server Details
The first fiscal MCP server for Spain: IAE/CNAE 2025, AEAT modelos, IRPF/IVA, RETA quota.
- 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 3.6/5 across 10 of 10 tools scored. Lowest: 3/5.
Most tools have distinct purposes, but calendario_fiscal and obligaciones_fiscales both relate to tax obligations and could be confused. However, their descriptions clarify that the former focuses on deadlines and the latter on applicable models, so confusion is minimal.
Tool names mix verb_noun (buscar_codigo, describe_conversor) and noun_noun/noun patterns (calendario_fiscal, detalle_cnae, modulos_irpf_iva). The pattern is not uniform, but names remain readable and indicative of function.
With 10 tools, the server covers a focused domain (IAE/CNAE information and related fiscal data) without being overwhelming or sparse. Each tool serves a clear purpose within that scope.
The tool set provides search, detailed lookup, fiscal calendar, batch queries, and calculations (RETA, modules). An explicit conversion tool between IAE and CNAE is missing, but the association is covered in detail tools, so agents can work around this gap.
Available Tools
10 toolsbuscar_codigoBuscar códigoBRead-onlyInspect
Busca códigos IAE/CNAE por descripción (búsqueda semántica). Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| type | No | ||
| top_k | No | ||
| threshold | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds minimal behavioral context. It includes 'Sin clave' (no key), hinting at authentication requirements, but does not elaborate on 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 extremely concise with two sentences, no wasted words, and directly states the core purpose.
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 having 4 parameters and no output schema, the description fails to explain parameters, return values, or usage details, making it incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no explanation of parameters (q, type, top_k, threshold). The agent gains no additional meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for IAE/CNAE codes by description using semantic search, which is specific and distinct from sibling tools that retrieve details by code.
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 detalle_cnae or detalle_iae. The description only explains what it does, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calendario_fiscalCalendario fiscalBRead-onlyInspect
Modelos AEAT y próximos plazos para un código IAE/CNAE. Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| code_type | No | iae |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so the tool is read-only. The description adds 'Sin clave' (without key), implying no authentication is needed, but this is vague. No behavioral traits beyond what annotations provide are disclosed. 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 a single, front-loaded sentence. It is concise with no wasted words. However, it is so brief that some necessary information is omitted, making it less effective than a slightly longer but more complete description.
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 (2 params, no nested objects, no output schema) and the presence of sibling tools, the description is minimally complete. It names the output 'Modelos AEAT y próximos plazos' but lacks details on format, pagination, or error cases. The agent may need to infer the response structure.
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 schema description coverage at 0%, the description must compensate. It mentions 'código IAE/CNAE', hinting that the 'code' parameter is such a code, and implies 'code_type' exists via the mention of 'IAE/CNAE'. However, it does not explain the default value, the pattern, or the optional nature. The agent may struggle to construct valid input.
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 provides AEAT models and upcoming deadlines for a given IAE/CNAE code. It identifies the resource (calendario fiscal) and the action (retrieve deadlines). However, it does not differentiate it from sibling tools like 'obligaciones_fiscales', which may overlap.
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 given on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consulta_masivaConsulta masivaARead-onlyInspect
Hasta 50 fichas IAE o CNAE en una llamada. Solo con clave de pago (Authorization: Bearer cvr_…).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| codes | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the batch size limit ('Hasta 50 fichas') and authentication requirement, enhancing transparency without contradicting 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 function, no redundant words. Every sentence provides critical 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 low complexity (2 simple params, no output schema), the description covers purpose, constraints, and auth. It is missing explicit mention of return format or error handling, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it only hints at the 'type' parameter ('IAE o CNAE') and does not explain the 'codes' parameter beyond its existence. The schema provides the structure, but the description adds minimal 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 it performs a batch query of up to 50 IAE or CNAE records in one call. This distinguishes it from sibling tools like 'detalle_iae' and 'detalle_cnae' which handle single records.
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 specifies the requirement of a payment key ('Solo con clave de pago') and the batch limit, implying it's for bulk queries. However, it does not explicitly state when to use this tool versus individual lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cuota_retaCuota RETA 2026ARead-onlyInspect
Calcula el tramo y la cuota mínima estimada de autónomos (RETA) por rendimiento neto. Solo con clave de pago (Authorization: Bearer cvr_…).
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | ||
| neto | Yes | ||
| tabla | No | general |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint. Description adds auth key constraint but no details on effects of missing keys or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and auth requirement with 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?
Covers purpose and auth constraint. Missing output format details, but sufficient for a simple calculator tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema description coverage; description only mentions 'neto' implicitly. Does not explain 'anio' or 'tabla' options or their defaults.
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 it calculates the bracket and minimum estimated quota for self-employed (RETA) based on net income. Distinct from siblings which cover tax codes and calendars.
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?
Specifies auth requirement but no explicit when-to-use vs alternatives. Context is clear but lacks exclusions or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_conversorDescribe ConversorARead-onlyInspect
Auto-descripción del servicio: catálogos, RPCs y frescura de datos. Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that no key is required and mentions data freshness, providing useful context 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?
The description is a single sentence with no wasted words. It is front-loaded with the core purpose.
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 zero parameters, no output schema, and a simple self-descriptive purpose, the description fully covers what the tool does and what it returns.
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% trivial). The description explains the tool's purpose, which serves as sufficient semantic context for an inputless tool.
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 is a self-description of the service covering catalogs, RPCs, and data freshness. This distinguishes it from sibling tools focused on specific tax/code lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (get metadata about the service), but there is no explicit guidance on when to use this vs alternatives or conditions like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detalle_cnaeDetalle CNAEARead-onlyInspect
Ficha completa de un código CNAE 2025 y sus IAE asociados. Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond the annotation readOnlyHint=true. The phrase 'sin clave' is ambiguous and does not significantly clarify behavior. No additional constraints or side effects are mentioned.
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 front-loads the key purpose without any 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 low complexity (1 param, no output schema), the description provides basic context but lacks detail on the return structure or what 'complete file' entails. It is sufficient for a simple lookup but not fully comprehensive.
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 0%, and the description only mentions the code concept without elaborating on format or meaning beyond the schema's pattern. This does not adequately compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a complete file for a CNAE 2025 code and its associated IAE, distinguishing it from sibling tools like detalle_cnae_2009 and detalle_iae.
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?
Although not explicitly stating when to use, the title and description imply it is for CNAE 2025 codes, and the sibling names provide implicit usage context. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detalle_cnae_2009Detalle CNAE 2009ARead-onlyInspect
Ficha de un código CNAE 2009 (obsoleto) y su correspondencia a CNAE 2025. Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adding the mapping context is adequate. No mention of other behaviors, but nothing contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It could add minor details without harming 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?
With no output schema, the description should explain what the return value includes (e.g., description, correspondence). It only says 'Ficha' (file), leaving the agent unsure of the response structure.
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 0%, but the description clarifies that the 'code' parameter is a CNAE 2009 code. However, additional details like format beyond the regex pattern are not provided.
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 provides details of an obsolete CNAE 2009 code and its correspondence to CNAE 2025. It distinguishes itself from the sibling 'detalle_cnae' which presumably handles current codes.
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 indication that the code is 'obsoleto' implies use for legacy codes, but no explicit guidance on when to use this tool versus siblings like 'detalle_cnae' or 'buscar_codigo' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detalle_iaeDetalle IAEBRead-onlyInspect
Ficha completa de un epígrafe IAE y sus CNAE asociados. Sin clave.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that the tool returns 'complete card' and includes associated CNAE, complementing the readOnlyHint annotation. No contradictions, but no further behavioral details.
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 exceptionally concise with two well-structured phrases, containing no extraneous 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?
Adequately covers purpose for a simple tool, but lacks details on output format, error conditions, or usage examples, which 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?
The sole parameter 'code' is not explained beyond schema pattern; the phrase 'Sin clave' is ambiguous and does not clarify parameter meaning or usage.
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 retrieves a full card of an IAE epígrafe and its associated CNAE codes, distinguishing it from sibling tools like detalle_cnae.
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 that this tool is for IAE details, but no explicit when-to-use or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modulos_irpf_ivaMódulos IRPF/IVABRead-onlyInspect
Régimen de estimación objetiva (módulos) de un IAE. Acepta un slug opcional para desambiguar códigos con varias actividades. Solo con clave de pago (Authorization: Bearer cvr_…).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| slug | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it requires a payment key (Bearer cvr_…), which is a behavioral trait. The annotation 'readOnlyHint: true' aligns with the read nature. However, it does not disclose what happens on invalid codes or rate limits.
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-loaded with the core purpose, and every sentence is informative. No redundancy.
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 lookup tool with 2 parameters and no output schema, the description covers the main purpose, the disambiguation feature, and auth requirement. It is fairly complete but could mention expected response structure.
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 0%, so the description carries the burden. It explains the 'slug' parameter (optional disambiguation) but does not add meaning to the required 'code' parameter beyond its pattern.
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 retrieves the objetiva estimation regime (módulos) for an IAE activity. It mentions the optional slug for disambiguation. However, it does not explicitly differentiate from siblings like 'detalle_iae', which might also provide details on an IAE.
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 only notes authentication requirements (payment key). It provides no guidance on when to use this tool versus sibling tools (e.g., 'detalle_iae', 'consulta_masiva') or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
obligaciones_fiscalesObligaciones fiscalesARead-onlyInspect
Modelos AEAT aplicables a un código (confianza, motivo, periodicidad, plazo). Solo con clave de pago (Authorization: Bearer cvr_…).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| code_type | No | iae |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds an important behavioral detail: the necessity of a payment key (Authorization header). No further disclosure of traits like error handling or response structure is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, effectively front-loading the core purpose and a key requirement. However, it lacks structure and could benefit from a brief mention of parameters.
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 simple input schema and presence of annotations, the description covers the main purpose and authorization requirement. It lists some output attributes, providing partial completeness. However, it omits parameter details and error handling, leaving minor 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 description coverage is 0%, and the description does not elaborate on the two parameters. It mentions 'código' generically but does not explain 'code' format or 'code_type' enum values. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 'Modelos AEAT' applicable to a code, listing specific attributes (confianza, motivo, periodicidad, plazo). This distinguishes it from siblings like buscar_codigo (which searches codes) or calendario_fiscal (fiscal calendar).
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 mentions a payment key requirement ('Solo con clave de pago'), but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It implies a usage scenario but lacks exclusions or comparisons to sibling tools.
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!