Plant Builder
Server Details
Run Plant Builder production-plant simulations with tunable knobs for goals, rates, and shifts.
- Status
- Unhealthy
- 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 9 of 9 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: the reference guide, demo listing, and specific run commands for different simulation models. Descriptions explicitly differentiate the demos by their systems and outputs.
All tool names follow a consistent snake_case pattern with verb_noun structure: get_pb_theory, list_demos, run_*. The naming is predictable and uniform.
With 9 tools, the set is well-scoped for a simulation demo server: one reference, one listing, and seven distinct run commands. Each tool earns its place without redundancy.
The set covers the core user journey: learn concepts, browse demos, and run each model. A minor gap is the absence of tools for creating custom simulations or retrieving historical run data, but the demos are self-contained.
Available Tools
9 toolsget_pb_theoryAInspect
Get a reference guide to Plant Builder simulation concepts: SLC, OLC, campaigns, shift patterns, scheduled DT, distribution control, goal blocks, equipment failures, DES+DRS bridge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only states it's a reference guide with no side effects. Lacks details on whether it's cached, read-only, or static. Adequate for a simple retrieval.
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 listing all key concepts without waste. Front-loaded with main 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?
Lists covered concepts adequately. No output schema, but description implies a textual guide. Could mention format or how to use, but sufficient for the scope.
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, baseline is 4. Description adds no parameter info, but 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?
Clear verb 'Get' and specific resource 'reference guide to Plant Builder simulation concepts', listing key topics. Distinct from sibling 'run_*' tools which execute simulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for learning concepts before running simulations. No explicit when-not or alternatives, but context suggests it's a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_demosAInspect
List available Plant Builder demos with descriptions and available knobs.
| 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 carries the burden. It clearly indicates a read-only listing operation with no side effects. Could mention if any auth is needed, but for a simple list it's 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?
Single sentence, front-loaded with the verb 'List'. No wasted 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?
Given no parameters and no output schema, the description covers the basic purpose. Could elaborate on what 'knobs' means, but still adequate for a simple listing 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?
There are zero parameters, and schema description coverage is 100%. No additional parameter info needed, baseline is 4.
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 lists demos with descriptions and knobs. It does not explicitly differentiate from siblings, but the name and context make it distinct from run or theory 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?
No explicit when-to-use or when-not-to-use instructions. Usage is implied by the name, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_chocolate_processingAInspect
Run the Chocolate Processing demo — the flagship PB model. 3 Systems (BeanProcessing, CocoaPowder, Chocolates), 15 Campaigns, full control stack (SLC, OLC, Shift, Scheduled DT, DC, Goal, Equipment Failures) with DRS overlay. 15 named knobs for campaign goals, equipment times, failure rates, shift pattern, and maintenance. Returns campaign timeline + DRS buffer levels.
| Name | Required | Description | Default |
|---|---|---|---|
| bp_goal | No | BeanProcessing goal for all 5 runs | |
| cm_goal_1 | No | Chocolate Making Campaign 1 goal | |
| cp_goal_4 | No | Cocoa Powder Campaign 4 goal | |
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. | |
| press_time | No | CocoaPowder Press processing time (Normal mean, min/unit) | |
| mixer2_time | No | Chocolates bottleneck Mixer 2 processing time (Normal mean, min/unit) | |
| mixers_mtbf | No | Mixers Mean Time Between Failures in minutes (hits both Mixer 1 and Mixer 2) | |
| mixers_mttr | No | Mixers Mean Time To Repair in minutes | |
| breaker_mtbf | No | Breaker Mean Time Between Failures in minutes | |
| breaker_mttr | No | Breaker Mean Time To Repair in minutes | |
| breaker_time | No | Global bottleneck Breaker processing time (Normal mean, min/unit) | |
| shift_pattern | No | Shift pattern: 1 = 5-day/2-shift (default), 2 = 7-day/3-shift (24/7) | |
| washdown_hour | No | Daily washdown start hour (24h) | |
| separator_time | No | BeanProcessing Separator processing time (Normal mean, min/unit) | |
| washdown_hours | No | Daily washdown duration in hours | |
| changeover_delay | No | Inter-Campaign changeover gap in minutes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses key behaviors: runs a demo, includes multiple systems, control stack, and returns specific output. It does not explicitly state read-only or idempotent nature, but for a demo simulation the behavioral traits are well conveyed.
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 consists of three concise sentences: the first states the core function, the second summarizes the demo's scale and features, and the third specifies the output. Every sentence adds value with 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?
Given the high parameter count (16) and absence of output schema, the description covers the tool's purpose, scope, and output format well. It could elaborate on the return structure (e.g., format of campaign timeline and buffer levels) but the essential context for agent selection and invocation 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?
The input schema already provides 100% description coverage for all 16 parameters. The description adds a high-level categorization ('15 named knobs for campaign goals, equipment times, failure rates, shift pattern, and maintenance'), which groups parameters but does not add detailed meaning beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Run the Chocolate Processing demo' and identifies it as the 'flagship PB model', providing a clear verb+resource combination. It distinguishes from sibling tools by naming specific systems, campaigns, and control features unique to this demo.
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 guidance on when to use this tool versus alternatives. Usage is implied through the focus on chocolate processing, but no when-not or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_ice_cream_plantBInspect
Run the Ice Cream Plant demo. 5 Systems (2 Making + 3 Packing) with Flavor and Flavor+Size changeover bindings, Rates_Table. Returns per-System completion summary.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions it's a demo and returns a summary, but does not disclose side effects, permissions, or limits. Adequate but could be more explicit about behavior (e.g., idempotency, data modification).
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 with clear main action and key details. No wasted words, but could be better structured (e.g., bullet points) for easier consumption.
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 one parameter with good schema, no output schema, but return value mentioned. The description could provide more context on what the demo entails (simulation vs. real plant) and how it fits with sibling demos.
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% and the schema description for the 'overrides' parameter is detailed. The tool description does not add meaningful information beyond the schema, so 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 it runs the Ice Cream Plant demo, specifies 5 systems with two types of changeover bindings, and mentions return of per-system summary. This is specific and distinguishes it from sibling tools like run_vegetable_plant.
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 run_vegetable_plant or run_chocolate_processing. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_vegetable_fullBInspect
Run the Vegetable Full demo (S4). 1 Making + DC + 5 Packing at scale. 5 Surge Bins with 20% Split distribution. Returns campaign status, bin/sink levels, DC aggregate, assertions.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. |
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 only lists return values (campaign status, bin/sink levels, etc.) but omits side effects, mutability, permission requirements, or whether it modifies system state. Lacks behavioral context needed for safe invocation.
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?
Concise, bullet-point style front-loads purpose. Every sentence adds information, though structure could be improved by grouping related details.
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 schema richness, description leaves gaps: no definition of S4, 'Making + DC + 5 Packing' acronyms, or 'Surge Bins'. No output schema, and return values listed but not typed. Complex tool needs more context.
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% and description adds value beyond schema by explaining 'overrides' bypass named knobs and handle unknown keys with warnings. Provides meaningful context for the only parameter.
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 runs 'the Vegetable Full demo (S4)' and provides specific details about the scenario (1 Making + DC + 5 Packing, 5 Surge Bins, 20% Split distribution). It distinguishes from sibling tools like run_vegetable_phase_b and run_vegetable_plant by indicating this is the 'full' version.
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 vs alternatives. It doesn't mention prerequisites, limitations, or scenarios where other tools would be preferred. Simply states what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_vegetable_phase_bCInspect
Run the Vegetable Phase B demo. 1 Making + 1 Packing in direct series. Validates Source Schedule dependency mechanism. Returns campaign details + assertions.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool returns details and assertions but does not mention side effects, permissions, or state requirements. The term 'demo' suggests non-destructive testing, but this is not explicit.
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 (two sentences) and front-loads the action. Every sentence adds information, though '1 Making + 1 Packing in direct series' is slightly jargon-heavy. 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 has one optional parameter, no output schema, and no annotations, the description covers the basic purpose and return value. However, it lacks behavioral details and does not explain the significance of the returned 'campaign details + assertions' 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?
Schema coverage is 100% for the single parameter 'overrides', and the schema already describes it clearly. The description adds no additional meaning or usage context for this parameter, but the baseline of 3 is appropriate since the schema is sufficient.
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 runs the Vegetable Phase B demo with specifics (1 Making + 1 Packing) and mentions validating a dependency mechanism. It gives a concrete purpose and differentiates from sibling tools by naming the phase, but doesn't explicitly contrast with other run_vegetable_* 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?
No guidance on when to use this tool versus alternatives like run_vegetable_phase_c or run_vegetable_plant. It mentions validating a specific mechanism but doesn't state prerequisites or contexts where this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_vegetable_phase_cAInspect
Run the Vegetable Phase C demo. 1 Making + DC (3 Surge Bins) + 1 Packing. Multi-bin distribution routing via DRS Split. Returns campaign status, bin levels, assertions.
| 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 present, so the description must cover behavioral traits. It does not disclose side effects (e.g., state changes, resource consumption), authorization needs, or idempotency, which is insufficient for a tool that likely creates or modifies resources.
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 (two sentences) with no extraneous information. It front-loads the action and lists key components and outputs efficiently.
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 no parameters and no output schema, the description covers the basic functionality and return values, but lacks context on how Phase C fits into the overall demo suite or when to prefer it over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline score is 4 per guidelines. The description does not need to add parameter 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 states the tool runs a Vegetable Phase C demo with specific components (1 Making, DC with 3 Surge Bins, 1 Packing) and mentions multi-bin routing via DRS Split, clearly distinguishing it from sibling tools like run_vegetable_phase_b or run_vegetable_full.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., other phase demos or full runs). There is no mention of prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_vegetable_plantAInspect
Run the Vegetable Plant baseline demo (Phase A). 2 Making + 5 Packing systems with calendar-rigid scheduling. Foundation model for the DC progression series. Returns per-System completion summary.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. |
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 reveals 'calendar-rigid scheduling' and states return is a 'per-System completion summary.' However, it does not clarify if the operation is read-only, destructive, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter demo tool with no output schema, the description covers purpose, systems, scheduling trait, and return type. Lacks explicit differentiation from siblings but is otherwise sufficient.
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% for the single parameter 'overrides,' which is well-documented in the schema. The description adds no extra meaning beyond what the schema provides.
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 runs the 'Vegetable Plant baseline demo (Phase A)' and specifies the systems involved (2 Making + 5 Packing). It distinguishes from siblings by positioning itself as the foundation model in the DC progression series.
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?
Implies it's the starting point for the series but does not explicitly state when to use it versus alternatives like run_vegetable_phase_b or run_vegetable_full. No exclusions or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_waste_processingAInspect
Run the Waste Processing demo. 6 Systems modeling a nuclear waste facility over ~25 simulated years. Simple pipeline. Returns per-System completion summary.
| Name | Required | Description | Default |
|---|---|---|---|
| overrides | No | Raw cell-address overrides as {"TableName.FieldName[row]": value}. Keys are DB cell addresses (1-based row). Bypasses named knobs. Unknown keys are warned and skipped. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention whether the tool is read-only or has side effects, state changes, or prerequisites; only the return type and pipeline simplicity are noted.
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 at three sentences, front-loaded with the primary action, and wastes no 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?
The description covers high-level purpose and return value but lacks details on behavior (mutability, safety) and does not compensate for missing annotations. Given the single optional parameter and no output schema, it is adequate but not fully 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% (the 'overrides' parameter has a detailed description in the schema). The tool description adds no additional parameter meaning beyond what the schema provides.
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 runs a specific demo: 'Waste Processing demo,' with additional details (6 systems, ~25 years, simple pipeline) that distinguish it from sibling demo tools like run_chocolate_processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the demo name and description, but there is no explicit guidance on when to choose this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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!