Lotus — AI Citation Intelligence
Server Details
GEO Intelligence Engine for B2B. Analyze domains and fetch actionable defense code.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 10 of 12 tools scored.
Each tool targets a specific aspect: overall GEO analysis, individual metrics (bleed model, bot activity, citation verdict), quick win lifecycle (list, code, mark), artifact management (get, regenerate, verify), and sharing. No two tools serve the same purpose.
Most tools follow a verb_noun pattern (e.g., get_artifact, analyze_geo). The exception is mark_applied, which uses an adjective instead of a noun, but it still fits the verb_object pattern. Overall consistent and readable.
With 12 tools covering analysis, metrics, quick wins, artifacts, and sharing, the set is well-scoped for the GEO domain. Each tool has a clear role without being overwhelming or sparse.
The tool surface covers the core GEO workflow: analyzing state, retrieving specific data, managing quick wins, and verifying deployment. Minor gaps exist (e.g., no tool for updating configurations), but it handles primary use cases effectively.
Available Tools
12 toolsanalyze_geoARead-onlyInspect
Analiza el estado GEO de un dominio.
Sin api_key: retorna preview limitado (1/día por IP, 3/semana).
Con api_key válida: retorna análisis completo con métricas, bleed model y simulaciones.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with description. The description adds valuable rate limit details and feature differences between api_key states, going 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 concise with two sentences, front-loading the main purpose. 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?
Given the tool's simplicity (1 parameter, no output schema), the description adequately covers key behavioral aspects and rate limits, though output format could be mentioned.
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 single parameter 'domain' has no schema description, and the description does not elaborate on its format or constraints. With 0% schema coverage, the description should compensate but fails to.
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 analyzes the GEO status of a domain. While it doesn't explicitly distinguish from siblings, the context of competitor actions and quick wins makes it distinct.
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 conditional usage guidelines for with/without api_key, but lacks explicit when-to-use vs alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_artifactARead-onlyInspect
Retorna el artefacto más reciente (llms_txt o json_ld) del cliente autenticado:
contenido, versión, generated_at y status.
Usar cuando un agente necesite leer el llms.txt o JSON-LD generado para un cliente.
artifact_type debe ser "llms_txt" o "json_ld".
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_type | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds scope (authenticated client) and recency, but does not cover error handling, rate limits, or response format beyond listing fields. Adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states result, second gives usage context, third specifies allowed parameter value. No extraneous content, front-loaded with 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?
Description lists returned fields (content, version, generated_at, status) and artifact type. With no output schema, this covers the return structure. Missing potential error cases or handling of no artifact, but adequate for a simple retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description explicitly defines valid values for artifact_type as 'llms_txt' or 'json_ld', which is essential for correct invocation.
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 most recent artifact for the authenticated client, specifying artifact types (llms_txt, json_ld) and returned fields. This verb-resource combination is distinct from sibling tools like regenerate_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when an agent needs to read generated llms.txt or JSON-LD for a client.' This gives clear context, but lacks explicit exclusion or alternatives, though implied by sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bleed_modelARead-onlyInspect
Retorna el modelo de sangrado de tráfico (bleed model) del cliente autenticado:
métricas en cascada con sus *_source labels + cálculo de revenue en riesgo.
Usar cuando un agente necesite evaluar el impacto económico de la erosión
Zero-Click para un cliente específico.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not repeat safety traits. The description adds that the tool returns cascade metrics with labels and revenue calculation, which is useful but doesn't disclose additional behavioral details like authentication or rate limits. With annotations covering the core safety profile, a score of 3 is appropriate.
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 long, front-loading the purpose ('Returns...') followed by usage guidance ('Use when...'). Every sentence is meaningful and there is no redundancy or 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?
Given no output schema and no parameters, the description adequately covers what the tool returns and when to use it. It does not describe the exact structure of the output, but the high-level description ('métricas en cascada... cálculo de revenue en riesgo') is sufficient for most agents.
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 tool has zero parameters, and schema coverage is 100% trivial. Per guidelines, 0 params baseline is 4. The description does not need to explain parameters, and it doesn't add any confusion.
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 the 'bleed model' of the authenticated client, including cascade metrics and revenue at risk. It uses a specific verb ('retorna') and resource, and the sibling tools list shows no overlap, so it is well-distinguished.
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 says 'Use when an agent needs to evaluate the economic impact of Zero-Click erosion for a specific client,' providing clear context. It does not state when not to use or list alternatives, but given the tool's specificity, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bot_activityARead-onlyInspect
Retorna la actividad de crawlers IA sobre el dominio del cliente autenticado:
total de hits, breakdown por bot, últimos hits y last-seen por bot.
Usar cuando un agente necesite evaluar la frecuencia de rastreo de IAs
sobre un sitio en los últimos N días.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which matches the read-only nature. Description adds behavioral context: it returns activity for the authenticated client's domain (scope) and includes temporal dimension via the 'days' parameter. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes what is returned, second explains when to use. No unnecessary words, front-loaded with key information. Very concise and well-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?
Given low complexity (1 optional parameter, no output schema), the description adequately covers purpose, usage, and return content. Could include more detail on the return format or parameter constraints, but overall sufficient for the tool's simplicity.
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%, so the description must compensate. It indirectly references the parameter ('last N days') but does not name or detail the 'days' parameter explicitly. Provides enough context to infer purpose but could be more precise.
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 the tool returns AI crawler activity for the authenticated client's domain, including specific breakdowns like total hits, per-bot details, and last-seen times. The verb 'retorna' and resource 'actividad de crawlers IA' are specific, and the tool is distinct from sibling 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?
Explicit usage guidance: 'Use when an agent needs to evaluate the frequency of AI crawling on a site in the last N days.' It does not mention when not to use or alternative tools, but the context is clear and the siblings are sufficiently different to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_citation_verdictARead-onlyInspect
Retorna el score de citación más reciente del cliente autenticado junto con las
mediciones de esa misma semana (campos seguros, sin response_full ni
grounding_supports). Datos crudos — sin clasificación healthy/critical.
Usar cuando un agente necesite auditar el desempeño de citación generativa
(GEO) de un cliente: tasa de citación, posición promedio, sentiment,
competidores mencionados y fidelidad de entidad.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true. The description adds that data is raw without classification, excludes response_full and grounding_supports, and includes specific metrics like citation rate and sentiment. This goes beyond annotations but does not cover all behavioral aspects (e.g., authentication).
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 (3 sentences) with no redundancy. It is front-loaded with the main action and return value, followed by usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the returned data (citation score, weekly measurements, specific fields) and the intended use case. It covers all necessary information for an agent to decide to invoke this 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?
With 0 parameters, baseline is 4. The description compensates by detailing the returned data, which is the only relevant semantic aspect. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the most recent citation score and weekly measurements, with a specific verb 'Retorna' and resource 'citation verdict'. It differentiates from sibling tools like analyze_geo by focusing on citation performance metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when an agent needs to audit a client's generative citation performance', providing clear context. However, it does not specify when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitor_actionsARead-onlyInspect
Retorna las competitor actions pendientes y trabajadas para un dominio.
Requiere api_key válida (pro, growth, o agency).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context about returning competitor actions with statuses. However, it does not disclose additional behavioral traits beyond read-only, but is consistent 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 purpose, no unnecessary words. Efficient and clear.
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?
While the description covers purpose and authentication, it lacks details on output format and the meaning of 'pending and worked'. Given no output schema, some additional context 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 coverage is 0% and the description adds that the domain parameter specifies the domain of interest. It does not detail format or constraints, but provides basic 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 that it returns pending and worked competitor actions for a domain, using the verb 'Retorna' and specifying the resource. This distinguishes it from sibling tools like analyze_geo and get_quick_wins.
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 mentions the API key requirement, but provides no guidance on when to use this tool versus siblings. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quick_win_codeARead-onlyInspect
Genera código completo de implementación para un Quick Win (por hash).
Solo disponible para wins de tipo structured_data.
Requiere api_key válida.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | ||
| domain | 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 the requirement for a valid API key. However, it does not disclose error conditions, rate limits, or the nature of the generated code beyond being 'complete implementation code'.
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 short sentences: the main action, a constraint, and a prerequisite. Front-loaded and concise with 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?
No output schema exists, and the description does not explain what the generated code looks like (format, language, snippet size). The 'domain' parameter is also unexplained, leaving gaps for the 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?
With 0% schema description coverage, the description must compensate. It implicitly explains 'hash' but provides no clarification for the 'domain' parameter, leaving its purpose ambiguous.
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 generates complete implementation code for a Quick Win by hash, and specifies it's only for structured_data type, distinguishing it from siblings like 'get_quick_wins' and 'mark_applied'.
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 a clear constraint ('only for structured_data') that guides when to use this tool, but does not explicitly list alternatives or contrast with sibling tools like 'analyze_geo' or 'get_competitor_actions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quick_winsARead-onlyInspect
Retorna los quick wins pendientes y aplicados para un dominio.
Requiere api_key válida (pro, growth, o agency).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds no contradictory information. It does not elaborate on additional behavioral traits such as error handling or rate limits, leaving minimal added value.
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 that efficiently communicate the tool's purpose and a key requirement. No extraneous information is present.
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, read-only, no output schema), the description covers the core function and a prerequisite. However, it misses the opportunity to differentiate from sibling tools or clarify the concept of 'quick wins', which slightly reduces 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 input schema has 0% description coverage for the sole parameter 'domain'. The description does not explain the parameter beyond its type, failing to compensate for the absence of schema documentation. The parameter name is self-explanatory, but the tool definition should do more.
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 retrieves pending and applied quick wins for a domain, using a specific verb ('Retorna') and resource ('quick wins'). It distinguishes itself from sibling tools like 'analyze_geo' and 'get_competitor_actions' by its unique purpose.
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 prerequisite (valid API key of specific tiers), but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. The context is useful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mark_appliedAInspect
Verify-before-mark: verifica que el schema esperado este presente en el DOM
del sitio y marca el Quick Win como applied. Solo marca si el @type esperado
se encuentra en los schemas_found del dominio (best-effort, fallo seguro).
Requiere api_key valida.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | ||
| domain | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false), the description adds behavioral context: verification step, best-effort approach, safe fallback, and the need for a valid api_key. 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 concise with three front-loaded sentences, but it could be more structured by briefly explaining 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?
While the description covers main behavioral aspects, it lacks parameter details, return value information, and does not fully specify failure cases, making it only partially complete for an 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?
The input schema has 0% description coverage, and the description does not explain the meaning or usage of the 'hash' and 'domain' parameters. It fails to add 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 the tool's purpose: verifying the expected schema in the DOM and marking the Quick Win as applied. It distinguishes from siblings by emphasizing the verification step and the condition for marking.
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 that marking only occurs if the expected @type is found, implying when to use, but it does not provide explicit when-not-to-use guidance or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regenerate_artifactsADestructiveInspect
Regenera los artefactos GEO (llms_txt, json_ld, defense_nodes) del cliente
autenticado. Respeta cooldown de 6h y presupuesto Gemini diario.
Usar cuando un agente necesite forzar la regeneración de artefactos tras
cambios en el sitio o en la configuración de competidores/ventajas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. Description adds useful context: respects a 6h cooldown and daily Gemini budget, which are behavioral constraints beyond the annotation flags. 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?
Two sentences: first sentence defines the tool's action and constraints, second sentence provides usage context. No wasted words; front-loaded with essential 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?
For a zero-parameter tool with no output schema, the description covers the action, constraints, and usage scenario completely. It tells the agent exactly what happens and when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline score is 4. The description correctly doesn't add parameter info as none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool regenerates GEO artifacts (llms_txt, json_ld, defense_nodes) for the authenticated client, distinguishing it from sibling tools like get_artifact (retrieval) and analyze_geo (analysis). The verb 'regenerate' and specific artifact names provide precise 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?
Explicitly states when to use: 'when an agent needs to force regeneration after changes in site or competitor/advantage config.' It implies not to use frequently due to cooldown/budget, but doesn't list alternatives or when-not conditions explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_installationARead-onlyInspect
Verifica en vivo si llms.txt y JSON-LD están correctamente instalados en el
dominio del cliente autenticado. Retorna estado overall (fully_deployed /
partially_deployed / not_deployed) más el resultado detallado de cada artefacto.
Usar cuando un agente necesite confirmar que los artefactos GEO están serving
correctamente en el sitio del cliente.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the description adds value by detailing the live check behavior and the return of overall status plus detailed artifact results. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the action. Every sentence adds necessary information 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?
Given no parameters, annotations provided, and no output schema, the description sufficiently explains the tool's purpose, when to use it, and what it returns (overall status and detailed 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 tool has zero parameters. According to the guidelines, baseline for 0 params is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action: verifying live installation of llms.txt and JSON-LD on the authenticated client's domain. It uses specific verbs and resources, and distinguishes itself from sibling tools which focus on analysis, generation, or other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when an agent needs to confirm that GEO artifacts are correctly serving on the client's site.' It does not provide explicit when-not or alternative tools, but the context is clear given sibling tool names.
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!