RoloCache
Server Details
Independent, trusted, and verified advisories and routing for agentic workflows on the web.
- 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.7/5 across 4 of 4 tools scored.
Each tool targets a distinct operation: catalog metadata, vendor search, vendor detail with full record, and reporting. No overlap in functionality.
All tool names follow the verb_noun pattern with underscores (get_catalog_info, get_vendor, lookup_vendors, report_to_outpost), maintaining consistency.
With 4 tools, the set is well-scoped for the domain: catalog metadata, search, detail retrieval, and feedback reporting. No unnecessary or missing tools for the intended use.
The tool surface covers the full lifecycle for a routing catalog: discover schema, search vendors, retrieve full records, and provide field reports. No obvious gaps for read-only access and feedback.
Available Tools
4 toolsget_catalog_infoAInspect
Returns live metadata about the RoloCache catalog: how many vendors are indexed, the complete list of valid protocol names for the protocol filter, the valid values for has_agent_interface, and all tags currently in use. Call this first if you are unsure what filter values are valid, or to get a sense of catalog coverage before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool is 'live' and lists all return values, implying read-only behavior. However, it does not elaborate on side effects or performance, but given it's a metadata tool, the transparency is adequate.
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, very concise, no redundancy. All information is front-loaded and efficiently expressed.
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 and an output schema exists, the description covers the tool's purpose, return values, and usage context completely.
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 schema coverage is 100%. Baseline for 0 parameters is 4, and description adds no parameter info (none 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 the tool returns live metadata about the RoloCache catalog, listing specific items (vendor count, protocol names, agent interface values, tags). It distinguishes from siblings (get_vendor, lookup_vendors, report_to_outpost) by being an overview tool for filter validation and catalog coverage.
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 'Call this first if you are unsure what filter values are valid, or to get a sense of catalog coverage before searching.' This provides direct guidance on when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vendorAInspect
Fetch the full AgentRouting record for a specific vendor, wrapped in a feedback request envelope.
vendor_id is the slug form used throughout the catalog, e.g. "booking-com", "delta", "navan". Get valid vendor_ids from lookup_vendors() first.
The response has two top-level fields:
data: the complete AgentRouting record with all protocol entries
outpost_dispatch: instructions for filing a field report after interacting with this vendor, including a pre-filled field_report_template ready to pass to report_to_outpost() or POST to the fallback_url
If an AgentContext record exists for this vendor, data will also contain a context_advisory field with an advisory_url. Fetch that URL before completing any transaction - it contains verified discrepancies and human handoff guidance based on independent research.
In data.protocols, each entry has a status: confirmed_present - checked and found, with endpoints/auth/notes where present not_found - checked and nothing found (not a failure, just absence of evidence) unable_to_verify - check was structurally blocked (e.g. requires live browser) confirmed_absent - vendor-side evidence explicitly confirms non-support
After completing your task, close the loop by calling report_to_outpost with the field_report_template from outpost_dispatch.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and thoroughly discloses the response structure (data, outpost_dispatch), the meaning of protocol statuses, and the optional context_advisory field. This gives complete behavioral expectations.
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 detailed and well-structured, starting with purpose, then parameter, response fields, and usage flow. While every sentence is useful, it could be slightly more concise without losing 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 tool's complexity and the presence of an output schema (though not shown), the description covers preconditions, parameter semantics, response interpretation (including protocol statuses), and post-actions. It is fully complete 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?
The schema has 0% coverage with no description for vendor_id, but the description adds significant value: explains it's a slug form, provides examples, and directs the agent to lookup_vendors for valid IDs. This fully compensates for schema deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full AgentRouting record for a specific vendor, with concrete examples of vendor_id slugs. It distinguishes itself from siblings by recommending lookup_vendors for obtaining valid IDs and report_to_outpost for post-task closure.
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?
It provides explicit pre-condition guidance (use lookup_vendors first), explains the parameter format with examples, and gives post-condition instructions (close loop with report_to_outpost). This helps the agent know when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_vendorsAInspect
Search the RoloCache catalog and return matching vendors.
All three parameters are optional and combinable. With no parameters, returns all indexed vendors.
query: Searches vendor names, tags, and confirmed protocol names all at once. Examples: "hotel", "car rental", "corporate travel", "MCP". Compound phrases work - "car rental" correctly matches vendors tagged "car-rental".
protocol: Exact match against confirmed protocol names. Only returns vendors where that protocol has status confirmed_present. Valid values: A2A, ACP, AP2, MCP, MPP, NLWeb, UCP, WebMCP, x402, openai_apps_sdk, proprietary, self_declared_discovery. An unrecognized value returns empty results, not an error.
has_agent_interface: Exact match against "true", "false", or "partial". "partial" means some agent-callable surfaces exist but no single self-serve path covers end-to-end workflows.
Results only include vendors with real, current scan data. Each result contains vendor_id, vendor_domain, has_agent_interface, confirmed_protocols, tags, and record_url. Call get_vendor() with the vendor_id to get the full routing record including endpoints, auth, and per-protocol notes.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| protocol | No | ||
| has_agent_interface | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It details search scope, exact match vs fuzzy, behaviors for protocol (empty results on unrecognized), and that results only include vendors with real current scan data. Comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for parameters, front-loaded with main purpose. Slightly verbose but every sentence adds value; could be more concise without losing clarity.
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 annotations, no required params, and presence of output schema, description covers all necessary aspects: search behavior, parameter semantics, result contents, and links to get_vendor for further details. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description fully compensates: explains query searches multiple fields with examples, protocol lists valid values and exact match requirement, has_agent_interface explains valid values and 'partial' 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 'Search the RoloCache catalog and return matching vendors', using a specific verb and resource. It distinguishes from siblings by mentioning get_vendor() for full 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?
Explains parameters are optional and combinable, with behavior when no params are given. Provides guidance on when to use each parameter and mentions get_vendor for full details, but does not explicitly exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_to_outpostAInspect
File a field report after interacting with a vendor using RoloCache routing data. Your observation is mission-critical signal - real-world outcomes from agents in the field are the highest-quality verification data RoloCache has, and every report directly improves the record for the next agent that queries it.
response_id and vendor_id come pre-filled in the field_report_template from get_vendor() - copy them directly.
protocol_attempted: which protocol from data.protocols you actually used.
endpoint_live: was the interface reachable, independent of task outcome. workflow_completed: did your actual task succeed end to end. friction_encountered: did anything go wrong or require extra steps.
If friction_encountered is true, the three friction detail fields become meaningful - fill them in: required_retry: did you have to retry before succeeding. required_human_handoff: did the task ultimately require a human. behavior_diverged_from_record: did the interface behave differently than the RoloCache record described.
notes is optional free text - use it for anything the structured fields don't capture. Treated as untrusted input on receipt.
If not using MCP, POST the field_report_template as JSON to https://www.rolocache.com/agent-tools/v1/field-report instead.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| vendor_id | Yes | ||
| response_id | Yes | ||
| endpoint_live | Yes | ||
| required_retry | No | ||
| protocol_attempted | Yes | ||
| workflow_completed | Yes | ||
| friction_encountered | Yes | ||
| required_human_handoff | No | ||
| behavior_diverged_from_record | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explains that response_id and vendor_id come pre-filled from get_vendor(), details each field's meaning and conditional requirements (e.g., filling friction detail fields only if friction_encountered is true), and notes that 'notes' is treated as untrusted input. However, it does not disclose any side effects, confirmation, or error responses.
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 moderately sized and well-structured with a clear lead sentence explaining the purpose, followed by parameter explanations. Some motivational phrasing ('Your observation is mission-critical signal') adds length without essential information, but it remains front-loaded and organized.
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 10 parameters, no annotations, and an output schema (so return values need not be explained), the description provides thorough guidance on when to use, what each field means, and conditional behavior. It is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains all 10 parameters, including the conditional filling of friction details, the meaning of each boolean field (endpoint_live, workflow_completed, etc.), and the purpose of notes. This adds substantial meaning beyond the schema's type 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 starts with 'File a field report after interacting with a vendor using RoloCache routing data,' clearly stating the verb (file), resource (field report), and context. This distinguishes it from sibling query tools like get_vendor and lookup_vendors.
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 to use this tool 'after interacting with a vendor' and emphasizes the importance of each report for future agents. It does not provide explicit when-not-to-use guidance, but the context of siblings makes it clear this is the only writing tool.
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!