ocean-schedules
Server Details
Compare ocean carrier sailing schedules, transit times, and on-time reliability before you book.
- 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.7/5 across 9 of 9 tools scored. Lowest: 3.1/5.
Most tools have distinct purposes, but 'find_best_sailings', 'find_sailings', and 'get_schedules' could cause confusion despite descriptive clarifications. The overlap is manageable for an agent.
Tool names mix noun phrases (carrier_league, port_reliability) and verb phrases (compare_lanes, find_sailings), lacking a uniform verb_noun pattern. However, all use snake_case, maintaining some consistency.
With 9 tools, the set is well-scoped for exploring ocean schedules and reliability. No tool feels redundant or missing for the apparent domain.
The tools cover key aspects: carrier performance, lane comparisons, sailing queries, schedules, port congestion, and alerts. A minor gap is the lack of a tool to list carriers or ports, but this is not essential for the core functionality.
Available Tools
9 toolscarrier_leagueAInspect
Carrier league table — ocean carriers ranked by overall on-time reliability across all tracked lanes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It discloses the output is a ranking by on-time reliability, but does not mention data freshness, whether it's aggregated across all lanes, or if there are caveats. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the key term 'Carrier league table' and immediately explains the content. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is nearly complete for its simple purpose. It could benefit from mentioning the time period or data scope, but it provides enough context for an agent to understand the output.
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%. The baseline for zero parameters is 4. The description does not need to add param info.
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 a 'Carrier league table' ranking ocean carriers by 'overall on-time reliability across all tracked lanes.' The verb is implied ('ranked'), and the resource is 'ocean carriers'. It distinguishes from siblings like 'carrier_reliability' which likely provides per-carrier details.
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 explicit guidance on when to use this tool versus alternatives like 'carrier_reliability' or 'port_reliability'. The description does not provide context for when this broad ranking is preferable or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
carrier_reliabilityBInspect
On-time performance and delay distribution for a specific carrier (by SCAC), optionally on a given lane.
| Name | Required | Description | Default |
|---|---|---|---|
| carrier_code | Yes | Carrier SCAC, e.g. MAEU |
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 burden. It states the tool returns on-time performance and delay distribution, but does not disclose data time period, aggregation, pagination, or any safety considerations. Minimal behavioral context beyond the basic purpose.
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?
Single sentence, front-loaded with key purpose, no extraneous words. Efficiently communicates core function.
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 one-parameter tool with no output schema, the description covers the main functionality. However, it fails to address the missing lane parameter and does not describe the output structure, leaving gaps for an agent to infer.
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 100% description coverage for the single parameter carrier_code, so baseline is 3. However, the description mentions an 'optionally on a given lane' filter which does not appear in the input schema, creating confusion and misalignment. This reduces value added.
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 provides on-time performance and delay distribution for a specific carrier (by SCAC), with an optional lane filter. This is a specific verb-resource combo that distinguishes it from siblings like port_reliability and carrier_league.
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?
Description implies usage for carrier reliability queries, optionally on a lane, but does not explicitly state when to use this tool versus alternatives (e.g., compare_lanes, find_sailings). No prerequisites or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_lanesBInspect
Compare ocean carriers serving an origin→destination port pair, ranked by on-time reliability and transit time. Use this to decide which line to book.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin port UN/LOCODE, e.g. CNSHA | |
| destination | Yes | Destination port UN/LOCODE, e.g. NLRTM |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool ranks carriers by reliability and transit time but does not disclose the return format, pagination, or limitations. The behavior is under-specified for a comparison 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?
Two sentences, no filler. Front-loaded with the core action. Every word adds value, making it highly 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 the absence of an output schema, the description hints at the output (ranked list) but does not specify format, number of results, or included metrics. It is somewhat complete but leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described concisely. The description adds no new meaning beyond restating 'origin→destination'. Baseline 3 is appropriate as schema already documents parameters adequately.
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 compares ocean carriers for an origin-destination port pair, ranked by on-time reliability and transit time. It differentiates from siblings like carrier_reliability or transit_time but does not explicitly distinguish from carrier_league or find_best_sailings.
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 includes 'Use this to decide which line to book' as usage guidance, but it does not mention when not to use it or alternatives among siblings. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_sailingsAInspect
Decision query: the best upcoming sailings on a lane, ONE per carrier (next bookable departure), ranked. Filter by date window, max transit days, min on-time reliability, cut-off still open, and direct-vs-transshipment. Use this to answer "what should I book?".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest departure date YYYY-MM-DD (default: +60 days) | |
| from | No | Earliest departure date YYYY-MM-DD (default: today) | |
| sort | No | Ranking (default recommended = reliability blended with transit) | |
| origin | Yes | Origin port UN/LOCODE or name resolves upstream, e.g. CNSHA | |
| cutoff_open | No | Only sailings whose booking cut-off has not passed | |
| destination | Yes | Destination port UN/LOCODE, e.g. NLRTM | |
| direct_only | No | Exclude transshipment routings | |
| max_transit_days | No | Maximum transit time in days | |
| reliability_floor | No | Minimum 90-day on-time %, 0-100 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description characterizes it as a 'decision query' and lists functionality, but lacks explicit disclosure of read-only nature, outcome on no results, or authentication needs. With no annotations, the description carries full burden, and while it provides context, it does not fully cover behavioral traits beyond inferred read operation.
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?
Four sentences, no redundancy. The key purpose and filters are front-loaded. Each sentence serves a purpose, making it efficient and easy to parse.
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, filtering options, and usage hint. Lacks output format description (e.g., what fields are returned), but given no output schema and the tool's simplicity, it may suffice. Sibling differentiation is present.
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?
Parameter descriptions in schema are present (100% coverage), but the tool description adds meaningful context by explaining the filtering intent (e.g., 'cut-off still open' for cutoff_open, 'direct-vs-transshipment' for direct_only) and the overall ranking concept, enhancing understanding beyond individual parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns best upcoming sailings per carrier, next bookable departure, ranked, with filters. Distinguishes from siblings like find_sailings by specifying it's a decision query for 'what should I book?' and one per carrier.
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?
Description instructs to use for answering 'what should I book?' and lists filters, implying it's for selecting optimal sailings. However, it does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_sailingsBInspect
Observed and derived upcoming departures on an origin→destination lane, with carrier and frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin port UN/LOCODE | |
| destination | Yes | Destination port UN/LOCODE |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, mutability, pagination, or rate limits. It only states the tool provides 'observed and derived' departures.
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 concise sentence that front-loads the core purpose without 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 no output schema, the description partially compensates by mentioning return fields (carrier, frequency). However, it omits other likely fields like dates, times, or statuses, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context about 'origin→destination lane' but does not significantly enhance meaning 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 it finds upcoming departures on an origin-destination lane, with carrier and frequency. It uses a specific verb and resource, but does not explicitly differentiate from sibling 'find_best_sailings'.
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 on when to use this tool versus alternatives like 'find_best_sailings' or 'compare_lanes'. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schedulesAInspect
Published forward sailing schedules on an origin→destination lane: carrier, vessel, voyage, ETD/ETA and cut-offs, soonest first. Sourced from carrier connectors (and aggregator coverage). Use this to find concrete upcoming departures to book.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin port UN/LOCODE, e.g. CNSHA | |
| destination | Yes | Destination port UN/LOCODE, e.g. NLRTM |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data sourcing from carrier connectors and aggregator coverage, and ordering (soonest first). However, with no annotations, it lacks details on authentication, rate limits, or error behavior (e.g., no schedules found).
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: first explaining what the tool returns and its ordering, second advising when to use it. Every word adds value, 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?
Covers the tool's purpose, returned fields, ordering, and data source. Lacks mention of error handling or pagination, but for a simple two-parameter tool without output schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters as UN/LOCODE strings. The description adds example codes (CNSHA, NLRTM) but no additional meaning beyond the schema, resulting in a baseline score.
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 returns published sailing schedules for an origin-destination lane, listing specific fields (carrier, vessel, voyage, ETD/ETA, cut-offs) and ordering (soonest first). This distinguishes it from sibling tools like find_sailings or compare_lanes.
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 advises using this tool to find concrete upcoming departures to book. While it does not explicitly state when not to use it or list alternatives, the context brings clarity for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
port_reliabilityAInspect
Congestion and dwell signals for a port (UN/LOCODE) — average wait and vessels at anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | Port UN/LOCODE, e.g. NLRTM |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns 'congestion and dwell signals' with specific metrics, but does not mention whether the operation is read-only, any required permissions, data freshness, or limitations. Basic behavior is disclosed, but not 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?
The description is a single sentence, front-loading the main purpose and providing concrete examples. Every word is necessary; no filler or redundancy. Highly efficient.
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 tool with one required parameter and no output schema, the description covers the key functionality and metrics. It lacks information about the output format or data structure, but given the tool's simplicity, it is reasonably complete. Slight room for improvement by mentioning typical response fields.
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 100% coverage for the single parameter 'port' with a description and example. The tool description reinforces the UN/LOCODE format and example but does not add significant new meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'congestion and dwell signals' for a port, with specific metrics 'average wait and vessels at anchor.' It uses the specific verb 'signals' and resource 'port,' distinguishing it from sibling tools like 'carrier_reliability' which focus on carriers rather than ports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'carrier_reliability' for carrier-specific data. Usage is implied by the tool name and description, but no explicit context is given for selection over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transit_timeAInspect
Observed transit-time distribution (median / p90, in days) for a carrier on an origin→destination lane.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin port UN/LOCODE | |
| destination | Yes | Destination port UN/LOCODE | |
| carrier_code | No | Optional carrier SCAC to filter |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns observed median and p90 transit times in days, which is a read operation. However, it lacks details on data freshness, permissions, rate limits, or any side effects beyond the basic output.
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 immediately conveys the tool's purpose and output. It is concise with no unnecessary words or repetition.
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 the absence of an output schema, the description adequately specifies the output (median and p90 in days). It covers the essential input parameters and output format. Minor gaps exist, such as absence of error handling or data range details, but these are not critical for a simple query 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?
Schema description coverage is 100%, with each parameter well-described. The tool description mentions 'carrier' and 'origin→destination lane', which aligns with the schema but adds no new meaning beyond what is already in the parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns transit-time distribution (median / p90 in days) for a carrier on an origin-destination lane. It specifies the verb (observed), resource (transit-time distribution), and the scope (carrier, lane), distinguishing it from siblings like carrier_reliability or port_reliability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needed transit time statistics, but it does not explicitly state when to use this tool over alternatives like carrier_reliability or compare_lanes. No usage exclusions or context cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_laneAInspect
Watch a lane for schedule alerts (PAID): get emailed when a sailing on it is blanked, a booking cut-off is about to close, or a sailing slips. Also alerts on reliability drops. Returns the created watch.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin port UN/LOCODE, e.g. CNNGB | |
| alert_slip | No | Alert when a sailing slips vs schedule (default true) | |
| alert_blank | No | Alert on suspected blank sailings (default true) | |
| destination | Yes | Destination port UN/LOCODE, e.g. NLRTM | |
| alert_cutoff | No | Alert when a booking cut-off is closing (default true) | |
| carrier_code | No | Optional SCAC to scope the watch to one carrier | |
| cutoff_lead_hours | No | Hours before cut-off to alert (default 48) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool creates a watch, triggers email alerts for specific events, and returns the watch object. However, it does not mention side effects (e.g., overwriting existing watches), limits, or reversibility, leaving some behavioral gaps.
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 covering purpose, alert types, and output. No wasted words or redundant information, earning top marks for efficiency.
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 tool with 7 parameters and no output schema, the description covers core functionality (alerts, return value) but omits details on parameter defaults or constraints beyond the schema. Still, it provides enough context for an agent to understand 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?
Schema coverage is 100%, so baseline is 3. The description does not elaborate on any parameters; it only describes tool behavior. Since the schema already explains each parameter, the description adds no additional semantic value beyond baseline.
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 watches a lane for schedule alerts (blanking, cut-off closing, sailing slip, reliability drops) and returns the created watch. It uses a specific verb 'Watch' and resource 'lane', distinguishing it from siblings like find_sailings or carrier_reliability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives or provide exclusions. It implicitly suggests use for monitoring alerts, but lacks comparative guidance despite clear siblings like find_sailings or get_schedules.
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!