cesm-runner-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
All 17 tools have clearly distinct purposes, covering different stages of CESM case execution, container management, and configuration queries. No two tools appear to overlap in functionality, reducing the chance of misselection.
Naming Consistency4/5
Tool names consistently use lowercase with underscores and combine verbs and nouns. However, there is a minor inconsistency in order: some are verb_noun (e.g., build_sandbox) while others are noun_verb (e.g., case_build). Still, the pattern is predictable and readable.
Tool Count5/5
With 17 tools, the server is well-scoped for its purpose of running CESM cases. Each tool serves a distinct function without being excessive, covering setup, build, submit, monitoring, container management, and configuration.
Completeness4/5
The tool set covers the primary lifecycle of CESM case execution, including build, setup, submit, status checks, log tails, and XML modifications. Minor gaps like case creation or input data download are absent, but these are outside the stated 'runner' scope.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3/5.
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?
Without annotations, the description carries the full burden. It discloses that the tool reads specific files (CaseStatus log and env_build.xml), implying no side effects. However, it does not mention required permissions, input validation, or any potential performance impact for large cases.
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?
Two sentences, front-loaded with the main purpose. Each sentence adds value: the first states the output, the second clarifies data sources. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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, no annotations, and an output schema, the description is adequate but not fully complete. It mentions reading specific files and reporting completed steps, which covers the basic behavior. However, it doesn't describe the output format (though an output schema exists) or what 'full status' entails beyond steps.
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?
The single required parameter 'case_dir' has no schema description (0% coverage), so the description must compensate. It only implies a directory path is needed without specifying format, path conventions, or whether it must be absolute. The description adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the status of a CESM case, using 'build/run/submit' to specify scope. It distinguishes from sibling tools like 'get_job_status' which likely targets job queues, but could be more precise about what 'full status' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't explain how it differs from 'get_job_status' or whether it should be called after specific build steps. The context signals show 16 sibling tools, making this gap significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states it lists running sessions without disclosing behavioral traits such as effects, permissions, or response details. Minimal 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?
Two concise sentences with no extraneous information. Efficiently conveys core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return format is covered. Missing parameter documentation and behavioral details, but overall adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'runtime' with 0% schema coverage. Description does not explain its meaning, default, or allowed values. Fails to add value beyond 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?
Clearly states it lists running crocontainer sessions, identifying Apptainer/Podman containers by name. Distinct from sibling tools like 'start_container' or 'stop_container'.
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?
Implied usage for listing containers, but no explicit when to use or when not to use. No alternatives mentioned, though siblings suggest context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It describes the command execution and return value, but omits behavior on missing variables, invalid case_dir, or if the operation is idempotent and safe. Basic traits are covered, but depth is insufficient.
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 very concise: three sentences that front-load the purpose, then details. No wasted words, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters and no annotations, the description covers the basic workflow but lacks information on error handling, prerequisites (e.g., valid case directory), and output format despite an output schema existing. Adequate but not comprehensive.
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 description coverage is 0%, so description must compensate. It adequately explains the variable parameter with case sensitivity and the special --listall value, but does not describe the case_dir parameter beyond its role in the command. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a CESM XML configuration variable, with specific verb and resource. Examples are provided, but it doesn't explicitly differentiate from sibling tools like xmlchange.
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 querying variables and mentions case sensitivity and the --listall option. However, it lacks guidance on when to use vs alternatives or when not to use, e.g., for modification use xmlchange.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states the command runs inside a container and returns stdout+stderr, but does not disclose side effects, authentication needs, or error behavior. It does not mention that the container must be running (implied by 'running container session'), nor any potential destructive actions.
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 short and front-loaded. It uses a list format for parameters, which is clear. Every sentence adds value, though the runtime parameter could be better integrated. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 explaining return values, the description is fairly complete. It explains critical platform-specific behavior for case_dir. However, it omits details about the runtime parameter and error handling, which 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% but the description adds meaning for name ('session name from start_container'), case_dir (path details with platform differences), and command (examples given). The runtime parameter is mentioned only as default 'auto' with no explanation. Coverage is partial but adds value.
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 'Run a CIME command inside a running container session.' This distinguishes it from siblings like start_container (which starts a session) and case_build (a specific command). The verb 'run' and resource 'CIME command in container' are explicit.
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 when a container session is running and a CIME command needs to be executed. It provides platform-specific notes for case_dir but does not explicitly state when to use this tool over siblings like case_build or case_submit. No exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full transparency burden. It says 'stop and clean up' but does not specify whether the container is merely stopped or removed, what resources are released, or if the action is reversible. This ambiguity leaves the agent uncertain about side effects, especially for a potentially destructive operation.
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?
Two concise sentences with essential information front-loaded. No extraneous words. However, separating parameter documentation from the main description could improve clarity; as is, it mixes function and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains the tool's core purpose and key parameter linkage. With an output schema present, return values are covered. Missing context includes prerequisites beyond the session name, error conditions, and details on the 'clean up' process. For a stop tool with moderate complexity, the description is adequate but not thorough.
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 documentation coverage is 0%, forcing the description to explain parameters. Only the required 'name' is described ('session name passed to start_container'), while the optional 'runtime' (default 'auto') is completely omitted. The description adds minimal value beyond the schema for the name parameter and none for runtime, which could affect container behavior.
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?
Clearly states the action: 'Stop and clean up a container session' and explicitly links it to 'started with start_container', differentiating it from other container-related tools. The sibling 'start_container' confirms the paired usage.
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?
Provides straightforward usage context: this tool is for stopping a container session that was started with 'start_container'. Requires the session name from that prior call. Does not explicitly mention when not to use it or list alternatives, but the sibling list implies complementary tools like 'container_exec' for running commands.
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?
Describes the walk and identification logic, including output format. However, lacks details on performance, symlink handling, error scenarios, and permissions; no annotations to compensate.
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?
Two concise sentences with no wasted words. Front-loaded with action and resource, followed by identification and output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple listing tool with output schema present. However, critical parameter information is missing from both schema and description, reducing 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?
Schema has zero parameter descriptions. Description only indirectly implies search_root is the starting directory and max_depth limits recursion, but does not explicitly define them or their constraints.
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?
Clearly states it walks a directory tree and returns CESM case directories based on a specific identification criterion (CaseStatus file). Distinguishes well from siblings that operate on cases rather than listing them.
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?
Implies usage for finding CESM cases in a filesystem, but no explicit guidance on when to use this tool versus alternatives like get_case_status or specific case operation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes only that it runs ./xmlchange from the case directory with an example. No mention of side effects, required state of the case, or error conditions. With no annotations, this is insufficient.
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 with clear structure: purpose, example, advisory. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value description (despite output schema existing) and prerequisites like case_dir validity. For a change tool with no annotations, more context is needed.
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?
Adds meaning for 'variable' and 'value' via the example, but 'case_dir' is not explained. Schema coverage is 0%, so partial compensation.
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?
Clearly states 'Change a CESM XML configuration variable' with an example. Distinguishes from sibling xmlquery by recommending its use first.
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?
Recommends using xmlquery before changing, providing a usage guideline. However, does not elaborate on when it is appropriate to change variables or what prerequisites must be met.
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 mentions running './check_input_data' and returning output about missing files, but does not disclose whether the tool modifies anything, requires authentication, or has side effects. The return format is not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no redundant information. Excellent conciseness.
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 (1 parameter, output schema exists), the description covers the core purpose and behavior. It explains the script run and output type. Slightly deficient in parameter explanation but acceptable overall.
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?
The schema coverage is 0% with no parameter descriptions in schema. The description only implies 'case_dir' is the case directory path but does not explicitly explain its meaning or usage. Value added is minimal.
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 'verify' and the resource 'required input data files'. It explains what the tool does (check input data staging) and distinguishes from sibling tools like 'case_submit' or 'preview_run' by its specific focus on data validation.
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 checking data before running a case but does not explicitly state when to use or not use this tool compared to alternatives. No comparative guidance 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 exist, so the description must disclose behavior. It mentions running './preview_run' and showing output, but does not explicitly state that no modifications are made. The 'preview' term implies safety, but the agent could benefit from an explicit statement about side effects or required permissions.
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 purpose, and contains no unnecessary 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 single parameter and output schema, the description is mostly complete: it explains the tool's output and use case. However, it lacks documentation for the case_dir parameter, which is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the required parameter 'case_dir' at all. There is no guidance on what value to provide or any constraints. This is a significant gap.
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 function: 'Preview what a CESM run will look like without actually submitting.' It specifies what information is shown (PE layout, estimated memory, wallclock, batch script) and distinguishes from siblings like case_submit, which actually submits.
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 by stating 'without actually submitting' and 'useful for validating resource settings before committing to case_submit.' This implies when to use it (before case_submit) and implies the alternative (case_submit). However, it does not explicitly exclude other scenarios.
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 full burden. It discloses key behavioral traits: batch submission by default, synchronous execution when container+no_batch=True, and the interaction with crocontainer. It does not detail return values or failure modes.
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 concise with a clear purpose statement followed by essential usage notes. It avoids extraneous information and is well structured for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and an output schema not described, the description is insufficiently complete. It omits explanations for 'case_dir' and 'resubmit', and does not describe what the tool returns or any error conditions.
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?
The schema coverage is 0%, yet the description only indirectly explains 'container' and 'no_batch' through usage context. 'case_dir' (required) and 'resubmit' are not mentioned at all, leaving the agent without semantic guidance for these 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 'Submit a CESM case' with a specific verb and resource. It distinguishes this from sibling tools like get_case_status or preview_run by focusing on submission.
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 explicit guidance on using container and no_batch together, including the rationale and consequences. However, it does not contrast with alternatives like preview_run.
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?
Discloses performance differences (container: interactive, immediate; Derecho without container: 10-30 min batch) and notes the container parameter's effect. Lacks mention of side effects or whether it modifies files.
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?
Front-loaded with the main action, then provides usage guidance. Slightly verbose for a short description, but generally clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key usage scenarios but fails to document most parameters or describe the output. With an output schema present, lack of return explanation is partially mitigated, but parameter gaps reduce 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?
Only explains the container parameter; case_dir, sharedlib_only, and model_only are not described, despite 0% schema coverage. This leaves significant gaps for agent usage.
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 compiles a CESM case using './case.build'. This is distinct from siblings like case_setup and case_submit.
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?
Provides context on when to use container compilation (recommended for fast iteration) versus batch on Derecho, but doesn't explicitly mention when not to use the tool or alternatives among siblings.
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 the full burden. It reveals internal steps (reading log, querying scheduler) and return states (R, Q, C, F) including resource usage. This provides good transparency for a read-only operation.
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: purpose, process, return. Front-loaded with the primary action. No redundant information, 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?
The description covers purpose, process, and return values. It lacks mention of error conditions (e.g., no job found) or prerequisites, but given the single parameter and output schema, it is largely complete.
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% and the only parameter 'case_dir' is not explicitly described. The description implies its use via 'from this case' but lacks details on format or constraints, failing to compensate for the coverage gap.
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 function: checking PBS/slurm batch queue status for the most recent job. It mentions the specific schedulers and the verb 'check', making it distinct from sibling tools like 'get_case_status'.
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 after job submission but does not explicitly state when to use or avoid this tool, nor does it mention alternatives. Context is clear but lacks explicit 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?
With no annotations provided, the description carries the full burden. It discloses that the tool uses the CIME query_config script and returns long-name compsets and aliases, giving good insight into behavior and 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 is concise and front-loaded, with three short paragraphs covering purpose, parameters, and implementation. Every sentence adds value without redundancy.
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 tool purpose, parameters with examples, and mentions the underlying script and return format. With an output schema present, this is sufficiently complete for a simple list tool.
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 the description must explain parameters. It does so clearly, providing examples for cesmroot and filter, adding meaning beyond the bare schema types.
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 'List available compsets in a CESM installation', using a specific verb and resource. It is distinctly different from sibling tools like list_cases and list_containers, which handle different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_cases or other tools. There are no explicit 'when to use' or 'when not to use' statements.
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 description carries full burden. Discloses file generation, clean flag behavior, container usage, and order dependency. Lacks details on side effects, errors, or persistence requirements.
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?
Four concise sentences: primary action, outputs, optional flags, prerequisite. No unnecessary words. Front-loaded with key 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?
Given existence of output schema (not shown), description is fairly complete: covers purpose, outputs, special flags, and ordering. Could mention return value or log location but not critical for a setup tool.
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 0%, description compensates by explaining 'clean' and 'container' parameters. 'case_dir' is implicit but unambiguous. Adds value beyond 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?
Clearly states action (run ./case.setup), resource (CESM case), and generated outputs (namelists, batch scripts, env_mach_specific.xml), distinguishing from siblings like case_build.
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?
States prerequisite (must run before case_build) and explains optional parameters (clean, container). Does not explicitly specify when not to use or contrast with other setup options.
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 full burden. It transparently discloses bind mounts, default paths, platform-specific behavior, and the return value (session name). It does not explicitly mention side effects or destructive actions, but creating a session is inherently stateful.
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 clear section breaks for platforms. It front-loads the purpose. While slightly lengthy due to platform-specific details, every sentence adds necessary context, and there is no redundancy.
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 complexity (multi-platform, 5 parameters, no annotations), the description covers most aspects: behavior, parameter details, prerequisites, and output. A minor gap is the 'runtime' parameter default 'auto' is not fully explained (how auto-detection works).
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 description coverage is 0%, but the description thoroughly explains each parameter's purpose, defaults, and platform-specific meaning (e.g., sandbox_or_image differs for Derecho vs local). It adds value beyond the raw schema by describing how parameters interact with the runtime.
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 starts a persistent container session for interactive CESM runs. It distinguishes from siblings like `container_exec` (execution within a container) and `stop_container`. Platform-specific details (Derecho vs local) further clarify the tool's role.
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 explicit usage guidance for two platforms, including defaults, prerequisites (e.g., build_sandbox for Derecho), and required parameters (inputdata_dir mandatory on local). It does not explicitly state when to avoid the tool or alternatives, but the context is clear.
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 the full burden. It explains that the tool searches the case directory and run/ subdirectory for log files, and returns the last lines of the most recently modified matching log. This discloses key behavioral traits like file search and timestamp-based selection.
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 at four sentences, with the main purpose front-loaded. Every sentence provides essential information without redundancy.
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 simple function and the presence of an output schema, the description covers search behavior, component options, and line count. It could mention error handling or file existence, but is sufficiently complete for typical use.
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%, so the description fully compensates by explaining each parameter: case_dir (implied as directory to search), component (list of valid values), and lines (number of lines). This adds meaning beyond the schema's property names and types.
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 returns the most recent lines from a CESM run log, with a specific verb 'Return' and resource 'CESM run log'. It distinguishes itself from sibling tools which focus on building, submitting, or querying cases, not viewing 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 implies usage for viewing recent log output, but does not explicitly state when to use this tool versus alternatives. However, since no sibling tool provides log tailing, the context is clear.
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 provided, so description carries full burden. Discloses that it submits via qcmd if queue_walltime is set, takes ~1 hour, and is one-time. Could add more on error handling or file modifications, but sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adds essential information. Front-loaded with main purpose, then prerequisites, timing, and parameter details. 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?
For a tool with 2 parameters and an output schema, the description covers purpose, prerequisites, behavior, and parameter semantics. Complete for an agent to select and invoke correctly given sibling tools include start_container.
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 has 0% description coverage and provides only defaults. Description adds meaningful defaults (~/scratch/crocontainer_sandbox for sandbox_dir, 3h for queue_walltime) and explains their intent, fully compensating for the schema's lack of description.
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?
Clearly states the tool builds an Apptainer writable sandbox from a crocontainer registry image. Uses specific verb (Build), resource (Apptainer writable sandbox), and context (on Derecho). Distinguishes from sibling tools like start_container.
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?
Explicitly says this is a one-time setup step required before start_container and mentions it takes ~1 hour. Provides context on when to use (before start_container) but could explicitly mention when not to use (e.g., after sandbox exists).
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_cesm_runner MCP server](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_cesm_runner/badges/card.svg)](https://glama.ai/mcp/servers/CROCODILE-CESM/MCP_cesm_runner)

Score Badge

Copy to your README.md:

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

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_cesm_runner'

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