Run ANUGA flood simulations, track progress, and retrieve results on Hydrata Cloud.
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.
Average 4.4/5 across 9 of 9 tools scored.
Each tool targets a distinct resource and action: project listing vs. details, run polling vs. full details, and separate lifecycle operations (start/cancel/retry). No two tools overlap in purpose.
All tools follow a consistent verb_noun snake_case pattern (list_projects, get_run, start_simulation) with clear verbs. The compound get_run_status is still predictable.
9 tools is a well-scoped size for a domain focused on managing flood simulation runs. Each tool covers a necessary operation without redundancy.
The run lifecycle is complete: start, poll, retrieve results, cancel, retry. Minor gap is the lack of scenario creation or building tools, but the server appears to operate on pre-existing scenarios.
cancel_runAInspectCancel an in-flight simulation run.
Works on runs in built, queued, or computing status. Cleans up compute resources (terminates EC2 instance, Celery task, or Batch job).
Returns 409 if the run is already in a terminal state (complete, cancelled, or error).
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID to cancel |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and handles it well. It discloses meaningful behavioral details: it cleans up underlying compute resources (EC2, Celery, Batch job) and returns 409 on terminal states. This goes beyond a generic 'cancels the run' and helps an agent anticipate side effects and error conditions.
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 compact—three short paragraphs, each serving a clear purpose: the action, the state constraints and cleanup detail, and the error behavior. No redundant sentences or filler.
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 tool with an output schema, this description covers the essential context: the action, what happens under the hood, the valid states, and the key error response. It's sufficient for an agent to select and invoke 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 schema already provides 100% coverage of the single parameter (run_id, integer, required). The description adds no additional parameter-level detail beyond what the schema gives, so it meets the baseline but doesn't improve on it.
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 opens with a specific verb ('Cancel') and a concrete resource ('in-flight simulation run'). It clearly differentiates from siblings like get_run, start_simulation, and retry_run by indicating the cancellation action, and further specifies applicable run statuses.
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 states the supported statuses ('built, queued, or computing'), providing clear context for when cancellation is valid. It also notes that calling on a terminal state returns 409, implying a 'when not to use' condition, but it doesn't explicitly name an alternative tool for terminal states, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectAInspectGet details of a specific ANUGA project including its scenarios.
Returns the project name, projection (EPSG code), base map ID, and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explicitly lists return fields: 'project name, projection (EPSG code), base map ID, and configuration,' and notes that scenarios are included. The verb 'Get' clearly implies a read-only side-effect-free operation, which adds transparency beyond the schema's single parameter.
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, front-loaded with the purpose, and every sentence adds value: the first states the action and scope, the second enumerates return fields. 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?
The tool is simple (1 parameter, no nested objects) and has an output schema, so the description need not explain return values in detail. It adequately covers the core purpose and return content. However, it could briefly note that project_id is required or refer to list_projects for discovery, but that is not essential for completeness given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes project_id as 'The project ID' with 100% coverage. The description does not add any additional meaning or syntax to the parameter. Since schema description coverage is high, the baseline of 3 applies.
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 function: 'Get details of a specific ANUGA project including its scenarios.' It uses a specific verb ('Get') and resource ('specific ANUGA project'), and distinguishes from siblings like list_projects by specifying a single project and from get_scenario by covering project-level 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?
The description implies usage: it is for a specific project (by project_id), not for listing all projects. It does not explicitly mention alternatives or when-not-to-use, but the context is clear from the wording 'specific project' and the sibling list includes list_projects. No exclusions are necessary for this simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_runAInspectGet full details of a simulation run including timing and results.
Returns the complete run record: status, progress, timing (start/end timestamps, duration), compute details (backend, instance type, cost), mesh info, error messages, and result log. Use get_run_status for lightweight polling; use this for final results.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently lists the return fields (status, progress, timing, compute details, mesh info, error messages, result log), effectively conveying this is a read operation without explicit side effects. It doesn't mention authorization or failure behavior, but for a 'get' tool the disclosure is strong.
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 front-loaded with a clear one-sentence summary, followed by a concise bullet-like list of returned content and a usage tip. Every sentence earns its place with no filler or 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?
The tool is simple (one parameter) and an output schema exists, but the description still provides a thorough overview of the return values, making it complete for an agent to understand the tool's behavior. The guidance to use get_run_status for polling fills the only likely contextual gap.
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 already documents run_id with 100% coverage, so the baseline is 3. The description does not add extra semantics beyond 'run_id' being the identifier, but given a single, self-explanatory parameter, this is adequate.
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 uses a specific verb ('Get') with a clear resource ('full details of a simulation run') and explicitly distinguishes itself from the sibling tool get_run_status, making its purpose unmistakable. The phrase 'including timing and results' further narrows scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use get_run_status for lightweight polling; use this for final results.' This clearly states when to use this tool versus an alternative, which is model behavior for this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_run_statusAInspectLightweight status check for a simulation run (fast, <50ms).
Use this for polling instead of get_run. Returns only: id, status, progress_pct (0-100), eta_seconds, error_message, and compute_backend.
Poll every 5-10 seconds. Terminal states: complete, error, cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the tool is fast (<50ms), limited to specific return fields, and defines terminal states. This is substantial behavioral context beyond the bare function name and schema.
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 succinct and well-structured. It front-loads the core purpose in the first line, then adds usage guidance and terminal states in compact, information-dense sentences. No word is wasted.
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, output schema present), the description provides all necessary context: what it returns, when to use it, how often to poll, and what the end states are. It is complete for an agent to select and 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 schema already provides 100% coverage for the single run_id parameter. The description adds little parameter-specific detail beyond confirming it's the run ID, which is already in the schema. This meets the baseline for high schema coverage but does not exceed it.
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 identifies the tool as a lightweight status check for a simulation run, using the specific verb 'status check'. It also distinguishes itself from the sibling tool get_run by explicitly recommending it 'instead of get_run', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this for polling instead of get_run'. Provides concrete polling guidance ('Poll every 5-10 seconds') and lists terminal states, giving the agent clear operational instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scenarioAInspectGet scenario details including its current status and latest run.
The status field is computed from the latest run and will be one of: created, building, built, queued, computing, processing, complete, error, or cancelled. A scenario must be in 'built' status before it can be run.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project ID | |
| scenario_id | Yes | The scenario ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the status is computed from the latest run and enumerates all possible status values. It also highlights the 'built' prerequisite for running, adding behavioral nuance beyond a simple 'get'. It does not mention permissions, rate limits, or side effects, but for a read-only tool this 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?
The description is compact and front-loaded: the first sentence gives the core purpose, and the second adds necessary detail about status computation and a usage constraint. No redundant words or restatement of the tool name. Every sentence adds value.
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 2-parameter read tool with an output schema declared, the description fully covers the key aspects: what it returns (details, status, latest run), how status is derived, and an important prerequisite for using scenarios. The output schema accounts for field-level detail, so the description need not expand further.
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% coverage for both parameters (project_id and scenario_id), each described as 'The project ID' and 'The scenario ID'. The description does not add any additional meaning or relationship between the parameters, so it stays at the baseline of 3 for high schema coverage.
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 a specific verb and resource: 'Get scenario details including its current status and latest run.' It clearly distinguishes this from sibling tools: get_run and get_run_status are for runs, get_project is for projects, and list_* are for listing. The tool's scope (scenario details) is unambiguous.
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 gives context on when to use this: a scenario must be in 'built' status before it can be run, implying that this tool is used to check status prior to running. However, it does not explicitly mention alternatives or when not to use it, though the sibling list makes the differentiation reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsAInspectList ANUGA simulation projects accessible to the authenticated user.
Returns a paginated list of projects with their names, projections, and base map references.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Results per page, max 100 (default 100) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It states the operation returns a 'paginated list' and specifies the kind of content (names, projections, base map references), which conveys a read-only, non-mutating behavior. It does not explicitly mention lack of side effects, but 'List' inherently implies a safe 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?
The description is two sentences long and front-loaded with the primary verb and resource. Every sentence adds value: the first states the core function, the second details the return payload. No filler 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?
For a straightforward list operation with a full input schema and an output schema present, the description sufficiently covers purpose, scope, pagination, and return content. There are no obvious gaps, and the description is complete for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (page, page_size) with defaults and limits, achieving 100% coverage. The description adds no additional parameter-specific semantics beyond the general 'paginated list' phrase, so the baseline 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 verb 'List' and the resource 'ANUGA simulation projects' with a scoping qualifier ('accessible to the authenticated user'). It also mentions the returned data fields, which distinguishes it from sibling tools like list_runs and get_project.
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 clear context on what the tool does and its scope ('accessible to the authenticated user'), but it does not explicitly state when to use it over alternatives such as get_project. For a simple list tool, the use case is evident, but there is no explicit exclusion or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_runsAInspectList all simulation runs across all scenarios in a project.
Returns a paginated list of runs. Optionally filter by status to find active, completed, or failed runs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Results per page, max 100 (default 100) | |
| project_id | Yes | The project ID | |
| status_filter | No | Filter by status: created, building, built, queued, computing, processing, complete, error, cancelled. Omit for all. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination ('Returns a paginated list') and optional filtering by status, giving transparent expected behavior. It doesn't mention sorting or error handling, but for a read-only list tool, this 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, front-loaded with core purpose, no filler. 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?
Has an output schema, and description covers scope, pagination, and filtering. Combined with schema, the info is sufficient for an agent to invoke correctly. Slight gap on required project_id, but schema handles it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. Description adds semantic context by mentioning 'status filter' and 'paginated list', but doesn't go beyond schema. Thus baseline 3.
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 uses specific verb 'List' with resource 'all simulation runs across all scenarios in a project.' This clearly distinguishes from siblings like get_run or get_run_status which target specific runs.
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 context ('List all runs across all scenarios', filter by status) but doesn't explicitly name alternatives like get_run for single-run retrieval. Thus usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry_runAInspectRetry a failed simulation run.
Resets an errored run back to 'created' status and triggers a new package build. The same run ID is reused. Only valid when status is 'error'. Returns 409 for any other state.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID to retry |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the state reset, the triggering of a package build, the reuse of the run ID, and the error response for invalid states. This is strong behavioral context, though it stops short of describing any side effects or ownership/permission implications, which would have earned a 5.
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 and front-loaded with the primary purpose. Each subsequent sentence adds valuable detail about state, behavior, and constraints without fluff. It is well-structured with a clear hierarchy of 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 moderate complexity, the presence of an output schema, and sibling context, the description is complete. It covers the core operation, state transition, validity condition, and failure mode, leaving no critical gaps for an agent to misuse the 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?
The input schema already provides full coverage (100%) with a clear description for run_id ('The run ID to retry'). The description does not add additional parameter context beyond the schema, so the 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 identifies the action ('Retry a failed simulation run') and the resource (simulation run). It distinguishes from siblings like cancel_run and get_run by specifying the state transition from 'error' to 'created', making the tool's unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the only valid precondition (status is 'error') and the consequence for other states (returns 409). This provides clear when-to-use guidance. While it doesn't name alternative tools, the explicit state constraint effectively communicates 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.
start_simulationAInspectStart a flood simulation run for a built scenario.
The scenario must be in 'built' status. Returns 202 with the new run. The run transitions through: built → queued → computing → processing → complete.
After starting, poll get_run_status to track progress. Returns 409 if the scenario is not in the correct state.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes | The scenario ID to run | |
| compute_backend | No | Compute backend: 'local' (Celery), 'ec2' (dedicated instance), or 'batch' (AWS Batch spot, cheapest). Default: 'local' | local |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return status codes (202, 409), the full state transition sequence (built → queued → computing → processing → complete), and the need to poll. This is thorough behavioral disclosure.
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, front-loaded with purpose, and every sentence adds value (state requirement, status code, lifecycle, polling advice). No fluff 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?
Given the tool's complexity, the description covers preconditions, lifecycle, failure mode, and next step. The output schema exists for return details, and sibling tools like get_run_status are referenced. Complete for an informed 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 fully described. The tool description adds no extra parameter semantics beyond restating the built-status requirement, so the baseline of 3 applies.
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 'Start a flood simulation run for a built scenario' with a specific verb and resource. It distinguishes from sibling tools like cancel_run and get_run_status by focusing on initiation and referencing the run lifecycle.
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 clear context on when to use: requires scenario in 'built' status and advises polling get_run_status afterward. It does not explicitly mention when not to use or directly compare with retry_run, but the guidance is strong.
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.
No comments yet. Be the first to start the discussion!
