SWMM-MCP

by kLabUM

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
Disambiguation4/5
Most tools have distinct purposes targeting specific SWMM operations like model management, data retrieval, and plotting. However, some overlap exists between 'get_input_info'/'get_input_sections' and 'get_report_info'/'get_report_sections', which could cause confusion in selecting the right file section tool. Overall, descriptions help clarify, but minor ambiguity remains.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern throughout, such as 'list_models', 'run_model', and 'plot_output_data'. There are minor deviations like 'add_storage' (verb_noun) and 'change_conduit' (verb_noun) fitting the pattern, but 'prompt_model_upload' is slightly longer and less standard. Overall, naming is mostly predictable and readable.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a SWMM modeling server covering model upload, modification, running, and data analysis. It includes essential operations without being overly bloated, though it borders on heavy. The tools are well-scoped for the domain, with each serving a clear function.
Completeness5/5
The tool set provides complete coverage for SWMM modeling workflows, including CRUD-like operations (upload, duplicate, run), data retrieval (input/output/report sections), modifications (change storm, conduit, storage), and visualization (plotting maps, rainfall, output). There are no obvious gaps; agents can perform full lifecycle tasks from model setup to analysis without dead ends.
Average 2.9/5 across 18 of 18 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Runs a model' implies an action but reveals nothing about execution behavior—such as whether it's read-only or destructive, requires authentication, has rate limits, returns outputs, or handles errors. This lack of information is critical for a tool that likely performs a core operation like model execution.
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 with just two words, 'Runs a model', which is front-loaded and wastes no space. However, this brevity comes at the cost of under-specification, as it lacks necessary details for effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running a model (likely a key operation), no annotations, no output schema, and minimal parameter documentation, the description is severely incomplete. It fails to provide essential context such as execution behavior, output expectations, or error handling, making it inadequate for the tool's presumed role.
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 one parameter 'model_name' with 0% description coverage, meaning the schema provides no semantic details. The description 'Runs a model' does not add any meaning about this parameter—it does not explain what 'model_name' refers to, valid formats, or how it influences execution. This leaves the parameter entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Runs a model' is a tautology that merely restates the tool name 'run_model', providing no additional specificity. It does not clarify what 'running' entails (e.g., execution, simulation, inference) or what resource is involved (e.g., a specific model type or system). This minimal statement fails to distinguish the tool from potential alternatives like 'list_models' or 'get_model_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With sibling tools like 'list_models', 'get_model_info', 'duplicate_model', and 'upload_model', there is no indication of prerequisites, appropriate contexts, or exclusions. This leaves the agent without direction on selecting the correct tool for a given task.
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 provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list, implying a read-only operation, but doesn't specify details like whether it requires authentication, has rate limits, or what format the list is in (e.g., structured data or raw text). This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, though it could benefit from more detail given the lack of annotations and schema coverage.
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?
Given the complexity of a tool with one parameter, no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't provide enough context about the tool's behavior, parameter usage, or output format, making it inadequate for an agent to use effectively without additional information.
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 description mentions 'for a given model', which corresponds to the 'model_name' parameter in the schema, but with 0% schema description coverage, it adds minimal semantic value. It doesn't explain what 'model_name' entails (e.g., format, valid values, or examples), failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Returns a list of sections in the input file for a given model', which provides a clear verb ('Returns') and resource ('sections in the input file'), but it's somewhat vague about what 'sections' specifically means. It doesn't differentiate from sibling tools like 'get_input_info' or 'get_report_sections', leaving ambiguity about its unique purpose.
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 is provided on when to use this tool versus alternatives. With sibling tools like 'get_input_info' and 'get_report_sections' available, the description lacks any context about specific use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
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 provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('returns'), but does not specify permissions, error handling, rate limits, or output format. The mention of 'report file' hints at a file-based resource, but lacks details on access or constraints.
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 a single, clear sentence that efficiently states the tool's purpose without unnecessary words. It is front-loaded and avoids redundancy, though it could benefit from additional context to improve completeness.
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 tool has an output schema, the description does not need to explain return values. However, with no annotations and low parameter coverage, it lacks details on behavior, usage, and parameter meaning. It is minimally adequate but has clear gaps for a read operation with two required parameters.
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 compensate for undocumented parameters. It mentions 'model_name' and 'section' implicitly but does not explain their semantics, valid values, or examples. This leaves key details like what constitutes a valid section or model name unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'returns the contents of a section of the report file for a given model', which specifies the verb ('returns'), resource ('contents of a section of the report file'), and scope ('for a given model'). However, it does not distinguish this tool from sibling tools like 'get_report_sections' or 'get_model_info', leaving ambiguity about their specific differences.
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. It does not mention prerequisites, exclusions, or compare it to siblings such as 'get_report_sections' or 'get_input_sections', leaving the agent to infer usage from the name alone.
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 provided, the description carries full burden for behavioral disclosure. It mentions the tool 'displays it to the user' and 'Returns whether the operation was successful,' which gives some context about user interaction and return values. However, it lacks critical details: whether this is a read-only operation, what happens if the model doesn't exist, what format the map takes, whether it requires specific permissions, or any side effects. For a visualization tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address core functionality. The first sentence covers the main action and technology, while the second addresses return value. There's no fluff or redundant information, though it could be slightly more structured with parameter details.
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?
Given the complexity (visualization tool with user display), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the parameter, error conditions, what 'successful' means concretely, or how the map is presented. For a tool that likely involves graphics generation and user interaction, more context is needed.
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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It doesn't mention the 'model_name' parameter at all—no explanation of what it represents, format requirements, or where valid names come from (e.g., from list_models). The description adds no parameter semantics beyond what the bare schema provides.
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's purpose: 'Creates an interactive map of the SWMM model using Plotly and displays it to the user.' This specifies the verb ('creates'), resource ('map of the SWMM model'), technology ('Plotly'), and user-facing behavior ('displays it to the user'). It distinguishes from siblings like plot_output_data or plot_rainfall by focusing on model structure visualization rather than output data or rainfall plots.
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. It doesn't mention prerequisites (e.g., needing an existing model), when-not-to-use scenarios, or comparisons with similar tools like get_model_info or other plotting tools. The agent must infer usage from the purpose alone.
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 provided, so the description carries the full burden of behavioral disclosure. It mentions the tool 'displays' a plot and returns a name or error, but lacks critical details: whether this is a read-only operation, if it requires specific permissions, what format the display uses (e.g., GUI, file), or any side effects. For a visualization tool with zero annotation coverage, this leaves significant gaps.
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 two clear sentences: one stating the action and one about the return. It's front-loaded with the core purpose. However, the second sentence about return values could be integrated more smoothly, and there's room to add brief usage context without losing efficiency.
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?
Given the complexity (visualization tool with 1 parameter), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It omits parameter semantics, behavioral details (e.g., display mechanism, error conditions), and ties to sibling tools. The return value mention is helpful but insufficient for full contextual understanding.
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 input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'model_name' parameter. It doesn't explain what a model name is, how to obtain valid names (e.g., from 'list_models'), or any constraints. The description fails to compensate for the schema's lack of documentation.
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's purpose: 'Displays a timeseries plot of the model's rainfall to the user.' This specifies the action (displays), resource (rainfall timeseries plot), and target (user). However, it doesn't explicitly differentiate from sibling tools like 'plot_model_map' or 'plot_output_data' which suggests similar visualization functionality.
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. It doesn't mention prerequisites (e.g., needing an existing model), contrast with other plotting tools like 'plot_model_map' or 'plot_output_data', or specify appropriate contexts. The agent must infer usage from the tool name and description alone.
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 provided, the description carries full burden for behavioral disclosure. It implies a mutation ('Modify') but doesn't specify permissions, reversibility, side effects, or rate limits. The mention of returning 'Name of the new storm or error message' adds some context, but overall, critical behavioral traits are missing for a tool that modifies model data.
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 brief and front-loaded with the core action, using two sentences efficiently. However, the second sentence 'depth: Total rainfall depth in inches' is somewhat redundant with the first, slightly reducing conciseness, but overall it's well-structured with minimal waste.
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 2 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining 'depth' and hinting at return values. The presence of an output schema means the description doesn't need to detail return values fully, but gaps in parameter and behavioral context keep it at an adequate but incomplete level.
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 compensate. It explains 'depth' as 'Total rainfall depth in inches', which adds meaning beyond the schema's type 'number'. However, it doesn't address 'model_name' at all, leaving half the parameters undocumented. This partial coverage results in a low score.
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 action ('Modify the model's storm event') and specifies the resource ('to an 24-hour SCS Type 2 design storm of a given depth'), which distinguishes it from siblings like 'plot_rainfall' or 'run_model'. However, it doesn't explicitly differentiate from potential similar tools (e.g., 'add_storage' might also modify aspects), keeping it at 4 rather than 5.
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. It doesn't mention prerequisites (e.g., needing an existing model), exclusions, or compare to siblings like 'plot_rainfall' or 'upload_model', leaving the agent to infer usage from context alone.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool performs a change (mutation), but doesn't specify if it's destructive, requires specific permissions, has side effects, or details the response format. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for the task, earning a high score for conciseness.
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 tool has an output schema (which handles return values) and moderate complexity (3 required parameters), the description is minimally complete but lacks depth. It covers the basic action but misses behavioral context and parameter details, making it adequate but with clear gaps for a mutation tool.
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 description coverage is 0%, meaning none of the 3 parameters are documented in the schema. The description only implies 'new_diameter' is a parameter without explaining what 'model_name' or 'conduit_name' refer to, their formats, or constraints. It adds minimal value beyond the schema's structure.
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 action ('Changes') and the resource ('diameter of a circular conduit in the model'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'change_storm' or 'duplicate_model', which might also modify model properties, so it falls short of a perfect score.
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. It doesn't mention prerequisites (e.g., needing an existing model or conduit), exclusions, or related tools like 'change_storm' for context, leaving the agent to infer usage from the name alone.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool returns information (implying a read-only operation) and mentions the need for exact model name input, but lacks details on permissions, error handling, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, and the second provides essential usage guidance. Both sentences earn their place by adding value, with no redundant or verbose language. It efficiently communicates key information in minimal space.
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 tool's low complexity (1 parameter, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details there. However, for a tool with zero annotation coverage and sibling tools that might overlap (e.g., 'list_models'), the description could better address context and differentiation to be more 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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying that 'model_name' must be entered 'exactly as it appears in the list', which clarifies input requirements beyond the schema's type definition. However, it doesn't explain what constitutes a valid model name or reference the 'list_models' tool for context, leaving room for improvement.
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's purpose: 'Returns general information about a model.' It specifies the verb ('Returns') and resource ('general information about a model'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_models' or 'get_report_info', which prevents a perfect score.
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 minimal guidance: 'Be sure to enter the model name exactly as it appears in the list.' This hints at a prerequisite (knowing the exact model name) but offers no explicit advice on when to use this tool versus alternatives like 'list_models' or 'get_report_info'. There's no mention of use cases, exclusions, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool displays a plot and returns a data summary, but doesn't specify format, interactivity, or storage implications. Critical behavioral traits like whether this is a read-only operation, if it modifies data, or has performance considerations are omitted. The description adds minimal context beyond the basic action.
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 efficiently structured with the core purpose first, followed by parameter explanations. Each sentence adds value without redundancy. However, the parameter explanations could be more integrated with the purpose statement rather than appearing as a separate list.
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?
For a 4-parameter plotting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'full timeseries plot' means visually, what format the 'summary' returns, or how the plot relates to the data summary. Given the complexity of visualizing timeseries data across multiple models, more context about output behavior 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?
With 0% schema description coverage, the description must compensate for all 4 parameters. It provides examples for each parameter (e.g., 'node', 'J1', 'flow') and references another tool for valid values, adding meaningful context beyond the bare schema. However, it doesn't explain relationships between parameters or constraints, leaving gaps in understanding how they work together.
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's purpose: 'Displays a full timeseries plot to the user. Returns a summary of the data.' This specifies both the visual output (plot) and data return (summary), distinguishing it from siblings like plot_model_map or plot_rainfall. However, it doesn't explicitly differentiate from other plotting tools beyond the timeseries focus.
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. While it references 'get_output_variables' for parameter values, it doesn't explain when plot_output_data is appropriate compared to other plotting tools (plot_model_map, plot_rainfall) or data retrieval tools (get_output_objects, get_output_variables). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states that the storage node starts empty unless specified (via 'initial_depth'), which adds useful context about default behavior. It mentions the return value ('success message or error description'), but lacks details on permissions, side effects (e.g., impact on model integrity), or error conditions. This is a moderate effort but leaves gaps for a mutation tool.
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 two sentences that are front-loaded: the first covers the core action and key parameters, and the second addresses return values. There's no wasted text, but it could be slightly more structured (e.g., explicitly listing parameters). Overall, it's efficient and well-sized for the tool's complexity.
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 5 parameters with 0% schema coverage, no annotations, and an output schema (which handles return values), the description is moderately complete. It covers the basic purpose and some behavioral traits but misses parameter semantics and usage guidelines. For a mutation tool with multiple parameters, this leaves significant gaps, though the output schema reduces the need to explain returns.
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 compensate for all 5 parameters. It only implicitly references 'storage_volume_cuft' ('specified volume') and 'initial_depth' ('start empty'), leaving 'model_name', 'junction_name', and 'max_depth' unexplained. The description adds minimal meaning beyond the schema, failing to clarify parameter roles or constraints, resulting in inadequate documentation.
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 action ('Replace a junction with a cylindrical storage node') and resource ('junction'), specifying the type of storage node and that it can have a specified volume. It distinguishes from siblings like 'change_conduit' or 'change_storm' by focusing on storage nodes rather than conduits or storm-related changes. However, it doesn't explicitly differentiate from all siblings (e.g., 'duplicate_model' is unrelated).
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. It doesn't mention prerequisites (e.g., needing an existing junction), exclusions (e.g., when not to replace a junction), or refer to sibling tools like 'change_storm' for storm-related modifications. The only implicit context is that it operates on junctions, but this is insufficient for informed tool selection.
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 provided, the description carries the full burden of behavioral disclosure. It states it 'Returns a list,' implying a read-only operation, but doesn't specify if it's safe, has rate limits, requires authentication, or details the return format beyond 'list of variables.' This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 tool's simplicity (one parameter) and the presence of an output schema, the description is somewhat complete but lacks depth. It doesn't cover behavioral aspects like safety or context, and with no annotations, it should do more to compensate, though the output schema reduces the need to explain return values.
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 adds minimal semantics beyond the input schema, which has 0% description coverage. It mentions 'for a given model,' hinting at the 'model_name' parameter's purpose, but doesn't explain what constitutes a valid model name or format. With one parameter and low schema coverage, this provides some value but is insufficient for full clarity.
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 verb ('Returns') and resource ('a list of variables in the output file for a given model'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_output_objects' or 'get_model_info', which might have overlapping scopes.
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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone among many siblings.
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 provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list, implying a read-only operation, but doesn't cover aspects like error handling, rate limits, authentication needs, or the format of the returned sections. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for its simple 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?
Given the tool has one parameter and an output schema exists, the description is somewhat complete but lacks depth. It doesn't explain the relationship to sibling tools or provide behavioral context, which is needed since no annotations are present. The output schema may cover return values, but overall completeness is minimal.
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 schema description coverage is 0%, so the description must compensate. It mentions 'for a given model', which implies the 'model_name' parameter is required, but doesn't explain what constitutes a valid model name or provide examples. This adds minimal semantic value beyond the basic schema.
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 action ('Returns a list of sections') and resource ('in the report file for a given model'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_report_info' or 'get_input_sections', which likely serve related but different purposes.
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. It doesn't mention prerequisites, context for usage, or how it differs from sibling tools such as 'get_report_info' or 'get_input_sections', leaving the agent without clear usage instructions.
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 provided, so the description carries the full burden. It states the tool returns a list but does not disclose behavioral traits such as permissions needed, rate limits, error handling, or whether it's read-only (implied by 'Returns' but not explicit). This leaves significant gaps for a tool with no annotation coverage, warranting a 2.
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 appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds necessary context for 'object_type'. There is no wasted text, but it could be slightly more structured (e.g., bullet points for parameters), so it earns a 4 for efficiency with minor room for improvement.
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 tool has 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It explains the purpose and provides some parameter guidance but lacks behavioral details and full parameter semantics. The output schema mitigates the need to explain return values, but overall completeness is adequate with clear gaps, scoring a 3.
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 the description must compensate. It adds meaning for 'object_type' by providing examples ('node', 'link', 'subcatchment') and referencing another tool for a full list, which clarifies semantics beyond the bare schema. However, it does not explain 'model_name' or other parameter details, so it partially compensates but not fully, resulting in a baseline 3.
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's purpose: 'Returns a list of objects in the output file for a given model and object type.' It specifies the verb ('Returns'), resource ('objects in the output file'), and scope ('for a given model and object type'). However, it does not explicitly differentiate from siblings like 'get_output_variables' or 'get_input_info', which limits it to a 4 rather than a 5.
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 provides implied usage guidance by referencing another tool ('model_output_variables') for a list of object types, suggesting when to use this tool for retrieving object lists. However, it lacks explicit when/when-not instructions or alternatives compared to siblings like 'get_output_variables' or 'get_input_info', so it earns a 3 for implied context without clear exclusions.
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 provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list but doesn't specify what information is included in the list, whether it's paginated, if there are rate limits, or any authentication requirements. This leaves significant gaps in understanding the tool's behavior.
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 a single, clear sentence that efficiently conveys the core functionality without any unnecessary words. It is front-loaded with the main action and resource, making it easy to parse and understand quickly.
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 that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks details about the list format, such as whether it includes model names, IDs, or metadata, which could be helpful despite the output schema. For a simple list tool, this is acceptable but not comprehensive.
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 tool has 0 parameters, and the input schema has 100% description coverage, so there are no parameters to document. The description doesn't need to add parameter semantics, but it could have mentioned if there are implicit filters or options. A baseline of 4 is appropriate since no parameters exist.
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's purpose with a specific verb ('Returns') and resource ('list of available models in the server'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_model_info' or 'upload_model', which prevents a perfect score.
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, such as 'get_model_info' for detailed information on a specific model or 'upload_model' for adding new models. Without any context about usage scenarios or exclusions, the agent must infer this from the tool name alone.
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 provided, so the description carries full burden. It mentions a UI prompt but doesn't disclose behavioral traits like whether it's interactive, requires user input, affects system state, or has side effects. For a tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part earning its place.
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 tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks details on behavioral aspects (e.g., interactivity, side effects) and doesn't differentiate from siblings, leaving gaps in contextual understanding.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details beyond this, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
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's purpose: 'Prompts the user with a UI where they can upload a SWMM model.' It specifies the action ('prompts'), resource ('SWMM model'), and mechanism ('UI'), though it doesn't explicitly differentiate from sibling 'upload_model' which might serve a similar function.
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 is provided on when to use this tool versus alternatives like 'upload_model' or other model-related tools. The description only states what it does, without context for selection among siblings.
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 carries full burden but provides minimal behavioral details. It mentions the content should be '.inp file content', but lacks information on permissions, rate limits, error handling, or what happens on the server (e.g., overwrites, validation). This is inadequate for a mutation 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 extremely concise with two sentences that directly state the tool's purpose and parameter requirement. Every word adds value, and it's front-loaded with the core action, making it efficient 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?
Given the tool has an output schema (which reduces need to describe returns) but no annotations and low schema coverage, the description is minimally adequate. It covers the basic upload action and file type, but lacks details on behavioral traits and usage context, leaving gaps for a mutation 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?
The description adds meaningful context for parameters: 'model_name' and 'content' are implied, with 'content' specified as 'full .inp file content'. Since schema description coverage is 0%, this compensates well, though it could detail 'model_name' usage (e.g., naming conventions).
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 action ('Uploads') and resource ('a new SWMM model to the server'), specifying it's for new models. However, it doesn't explicitly differentiate from sibling tools like 'duplicate_model' or 'prompt_model_upload', which might handle similar upload scenarios.
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 is provided on when to use this tool versus alternatives. For example, it doesn't mention whether to use this for initial uploads versus updates, or how it relates to 'duplicate_model' or 'prompt_model_upload' in the sibling list, leaving usage context unclear.
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 provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns the new model name, which is useful, but fails to describe critical behaviors: whether duplication requires specific permissions, if it's a read-only or destructive operation, what happens to the original model, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
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 with two sentences that each serve a clear purpose: the first states the action and return value, the second provides usage context. There is zero wasted language, and it's front-loaded with the core functionality.
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 that there is an output schema (which should document the return value), the description doesn't need to explain return values in detail. However, for a mutation tool with no annotations and 0% schema coverage for parameters, the description is incomplete—it lacks details on permissions, side effects, and parameter meanings. It's minimally adequate but with clear gaps.
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%, meaning the schema provides no descriptions for the two parameters. The description adds no information about what 'model_name' or 'new_name' represent, their formats, constraints, or examples. It doesn't compensate for the lack of schema documentation, leaving parameters semantically unclear.
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 verb ('duplicates') and resource ('a model'), specifying what the tool does. It distinguishes from siblings like 'list_models' or 'run_model' by focusing on duplication rather than listing or execution. However, it doesn't explicitly differentiate from 'upload_model' or 'prompt_model_upload' in terms of source, which keeps it from a perfect score.
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 context for when to use this tool: 'for testing scenarios'. This gives clear guidance on its intended purpose. However, it doesn't specify when NOT to use it or mention alternatives like 'upload_model' for non-duplication cases, which prevents a score of 5.
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 returns contents (implying a read operation) and includes a constraint about bracket usage, adding some behavioral context. However, it lacks details on permissions, error handling, rate limits, or output format, which are important for a tool with parameters and an output schema. The description does not contradict any annotations, as none exist.
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 highly concise and front-loaded: the first sentence states the core purpose, and the second adds critical usage notes. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, 0% schema coverage, and an output schema exists, the description is reasonably complete. It covers purpose, parameter semantics, and usage guidelines, and the output schema likely handles return values. However, as a read operation with no annotations, it could benefit from more behavioral details like error cases or data format, slightly reducing completeness.
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%, so the description must compensate. It explains that 'model_name' refers to a given model and 'section' is a section of the input file, with additional guidance to avoid brackets and use 'get_input_sections' for valid sections. This adds meaningful context beyond the bare schema, though it could specify format examples or constraints more explicitly. With 0% coverage, this is above the baseline of 3.
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's purpose: 'Returns the contents of a section of the input file for a given model.' It specifies the verb ('Returns'), resource ('contents of a section'), and scope ('input file for a given model'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'get_input_sections' or 'get_model_info', though it references 'get_input_sections' for context.
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 usage context by stating 'Do NOT include brackets in the section name' and 'Refer to the tool get_input_sections for a list of sections.' This gives explicit guidance on parameter formatting and references an alternative tool for obtaining valid section names. However, it does not specify when to use this tool versus other siblings like 'get_model_info' or 'get_output_variables', limiting full differentiation.
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:

[![SWMM-MCP-PUB MCP server](https://glama.ai/mcp/servers/kLabUM/SWMM-MCP-PUB/badges/card.svg)](https://glama.ai/mcp/servers/kLabUM/SWMM-MCP-PUB)

Score Badge

Copy to your README.md:

[![SWMM-MCP-PUB MCP server](https://glama.ai/mcp/servers/kLabUM/SWMM-MCP-PUB/badges/score.svg)](https://glama.ai/mcp/servers/kLabUM/SWMM-MCP-PUB)

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/kLabUM/SWMM-MCP-PUB'

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