regional-ocean-debugger-mcp

by CROCODILE-CESM

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, ranging from CFL checks to error classification, parameter comparison, and diagnostics suggestions. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_cfl, find_errors, suggest_diagnostics) with no deviations.
Tool Count5/5
Eleven tools is an appropriate number for a specialized debugger, covering core tasks without being excessive or insufficient.
Completeness4/5
The tool set covers the main debugging workflow (error detection, classification, parameter analysis, diagnostics advice) but lacks a tool for direct parameter modification, which is a minor gap.
Average 4.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses search behavior (looks in case_dir and case_dir/run/) and returns the most recent match. However, it does not mention what happens if no log is found or how the 'lines' parameter controls the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses three concise sentences, front-loading the purpose and adding search behavior without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's core function and search logic. Minor gaps like the 'lines' parameter usage are present but do not severely hinder completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description only explains the 'component' parameter values, leaving 'case_dir' and 'lines' (which does have a default) without additional meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns recent lines from a CESM or MOM6 run log, specifies supported components ('cesm', 'ocn', etc.), and distinguishes it from sibling tools like read_diag_table or classify_error.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading run logs but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with siblings like read_diag_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly states that the tool returns differing parameters and side-by-side values, but does not disclose whether any side effects occur (e.g., file modification) or error conditions, which is adequate for a read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no fluff: first states purpose, second describes output, third gives use context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters and an output schema (not shown), the description covers the essential functionality. It could explicitly state that it works only for CESM/MOM6 cases, but the name and context imply this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention what 'case_dir_a' and 'case_dir_b' represent (paths to cases) or any format constraints, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compare' and resource 'MOM_input parameters between two CESM/MOM6 cases', clearly distinguishing it from sibling tools that perform different tasks like checking CFL or reading run logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Useful for diagnosing why two configurations behave differently', providing clear context for when to use. However, it does not explicitly exclude scenarios or mention alternatives, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses it searches and returns Q&A pairs, implying read-only behavior. No mention of side effects, authentication, or rate limits, but it is transparent about its core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, content list, and return format. It is concise but includes useful detail without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains the return (Q&A pairs). For a simple search tool, it covers enough context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the top_k parameter (default 5, max 10). The question parameter is implied by the tool's purpose but not detailed. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches expert interview transcripts for scientific guidance, specifying the resource and action. It distinguishes from sibling tools which deal with parameters, errors, diagnostics, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the knowledge base content, helping infer when to use (e.g., needing scientific guidance on MOM6 configuration). However, no explicit when-not or comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'Returns recommended values with caveats about bathymetry and tidal forcing,' but lacks details on computational cost, whether it uses empirical formulas or external data, and other behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bullet, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, returns values with caveats) and presence of an output schema (not shown), the description covers essentials. However, it could briefly mention that output schema explains return structure, and perhaps note it doesn't require complex inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the single parameter 'resolution_deg' with definition and example (e.g., 0.1 for 1/10°), adding meaningful context beyond the schema that only specifies type and required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests safe MOM6 timestep values (DT and DT_THERM) for a given grid resolution, with a clear verb and resource. It distinguishes from siblings like check_cfl and get_parameter_advice by focusing specifically on timestep suggestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool vs. alternatives. It implies usage for setting timesteps based on resolution, but no guidance on when not to use it or comparison with siblings like check_cfl or get_parameter_advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the search scope (all run logs), specific error indicators, and return format (structured list with filename, line number, error type). It does not mention permissions or side effects, but as a read-only scan, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the main purpose, enumerate error types, and provide actionable follow-up. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, scope, error types, and return structure. It does not explain CESM context or output schema details, but an output schema exists and domain knowledge is assumed. Slightly more detail on the case_dir parameter would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% since the description does not explicitly document the case_dir parameter. However, the context 'Scan all run logs in a CESM case' implies the directory, and the parameter name is self-explanatory. This partially compensates, but a direct statement would be stronger.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans run logs in a CESM case for error indicators, listing specific error types. It distinguishes from sibling classify_error by positioning itself as the detection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to find errors) and suggests a follow-up action (call classify_error). However, it does not explicitly state when not to use or compare with siblings like check_cfl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 matches against a library of known failure modes and returns structured diagnosis, which implies it is a read-only classification. However, it does not mention any side effects, error handling for unknown errors, or performance characteristics. While adequate for a simple classifier, more detail could improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no redundant information. Every sentence adds value: the first states the purpose and output, the second provides usage guidance. It is perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return value documentation), the description is complete. It covers what the tool does, how to use it, and what it returns. No additional details are necessary for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the description must add meaning. It does so by specifying that the parameter should be 'a snippet of error text (e.g. from find_errors output).' This clarifies the expected content and source beyond the schema's generic 'string' type. For a single parameter, this provides sufficient semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Classify a MOM6/CESM error message and return probable cause and fix suggestions.' It specifies the verb (classify) and the resource (error message), and implies the function of diagnosis. The context of use is clarified by mentioning input from find_errors, which distinguishes it from sibling tools like find_errors that only locate errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by suggesting to 'Pass a snippet of error text (e.g. from find_errors output).' This gives a clear use case and indicates the tool should be used after find_errors. However, it does not explicitly state when not to use it or mention alternatives, but the sibling list and context make the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full transparency burden. It implies a read-only operation by stating it reads and parses, but does not explicitly declare it non-destructive or mention side effects. The typical locations hint at the input, but permissions or lock behavior are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, each adding value: purpose first, then location and output structure. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the input (case_dir meaning and location) and output format (grouped by module/component). It is sufficient for the agent to use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description adds meaning by explaining the case_dir parameter's role and typical subpaths. This compensates for the bare schema, though it could include the expected format (e.g., full path).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Read and parse') and resource ('MOM6 diag_table from a CESM case'), and specifies that it returns enabled diagnostics grouped by module/component. This differentiates it from sibling tools like 'suggest_diagnostics' or 'read_mom6_params'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on typical file locations ('case_dir/run/ or case_dir/Buildconf/momconf/'), helping the agent understand when to use it. However, it does not explicitly exclude scenarios or mention alternatives, missing full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the source ('interview knowledge base') and what is returned (context, typical values, pitfalls), but doesn't mention behavior on missing parameters or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a front-loaded purpose, but the second sentence is somewhat redundant with the first, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple schema and an output schema (present but not shown), the description adequately covers the tool's use case. It could optionally mention that output is text-based, but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining the parameter is a MOM6 parameter name with examples (e.g., 'DT', 'MINIMUM_DEPTH'), adding significant meaning beyond the string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Look up', the resource 'expert guidance for a specific MOM6 parameter name', and differentiates from siblings like 'read_mom6_params' (values) and 'query_domain_knowledge' (general).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing expert advice on a MOM6 parameter, but does not provide explicit when-not or direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return format (KEY=VALUE pairs), override precedence (MOM_override marked with [override]), and basic usage. It does not mention error handling or non-existent files, but given the read-only nature, the transparency is good. No annotation contradiction (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, then detail the return format and filtering. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (reading two files, returning key-value pairs) and the presence of an output schema (so no need to explain return structure), the description covers all essential aspects: files read, return format, filtering, and override precedence. It is complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description bears the burden. It clearly explains the 'filter' parameter as a substring search with examples, and 'case_dir' is self-evident from context. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads MOM_input and MOM_override parameter files for CESM/MOM6 cases, returns KEY=VALUE pairs, and supports substring filtering. It distinguishes from sibling tools like diff_params (comparison) and find_errors (error detection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (read specific files) and how filtering works, but does not explicitly mention when to use it over alternatives or exclusions. The context is clear enough for selecting this tool for reading parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully describes the read-only behavior: it reads MOM_input parameters, compares them, and returns an assessment. It discloses limitations but does not mention any side effects or auth requirements, which are minimal here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear paragraphs: purpose, details, and a note on limitation. It is front-loaded with the main action and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 description covers input, process, output (stability assessment and flags), and a key limitation. An output schema exists separately, so missing return value details are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'case_dir' is not described in the input schema (0% coverage). The description fully compensates by explaining it as the path to the MOM6 case directory, from which it reads DT, DT_THERM, and resolution parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'CFL stability condition for a MOM6 case'. It distinguishes itself from sibling tools by focusing specifically on CFL stability using MOM_input parameters as a proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting that a full CFL check requires the actual grid file and that this tool is a quick proxy sanity check. However, it does not explicitly mention when to use alternatives like suggest_timestep or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool returns a list of diagnostics and is non-destructive, but lacks details on any limitations or quotas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences and a bullet-like example list, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of an output schema, the description provides sufficient context for usage, including input format and return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for 'symptoms' (0% coverage), but the description adds detailed examples and context, fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests MOM6 diagnostics for diag_table based on a problem description, using a specific verb and resource. It distinguishes from sibling tools like suggest_timestep by focusing on diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description guides on when to use (investigating problems) and provides input examples, but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP_regional_ocean_debugger MCP server](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_regional_ocean_debugger/badges/card.svg)](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_regional_ocean_debugger)

Score Badge

Copy to your README.md:

[![MCP_regional_ocean_debugger MCP server](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_regional_ocean_debugger/badges/score.svg)](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_regional_ocean_debugger)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CROCODILE-CESM/MCP_regional_ocean_debugger'

If you have feedback or need assistance with the MCP directory API, please join our Discord server