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 3.6/5 across 3 of 3 tools scored.
Each tool targets a distinct aspect of GEO analysis: state analysis, competitor actions, and quick wins. Descriptions clearly differentiate their purposes and API key requirements.
All tool names follow a consistent verb_noun pattern (analyze_geo, get_competitor_actions, get_quick_wins) using snake_case, making them predictable and easy to understand.
With only 3 tools, the set feels somewhat thin but still reasonable for a narrow specialization in citation intelligence. The tools cover core functionalities without being excessive.
The tools cover analysis, competitor actions, and quick wins, which are key for GEO management. However, missing operations like listing domains or generating broader reports represent minor gaps.
Available Tools
5 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_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.
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!