agentsumo-mcp

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, especially the pipeline steps (osm_extract, net_convert, etc.) and editing tools (edge_edit_tool, reduce_lanes_tool). However, multiple visualization tools (visualize_net_tool, visualize_edge_tool, visualize_policy_target_tool, visualize_edgedata_tool) and two vehicle generation tools (vehicle_generation_tool, flow_generation_tool) could cause some confusion despite clear usage instructions.
Naming Consistency3/5
The naming is mostly snake_case, but there is inconsistency: core pipeline tools omit the '_tool' suffix (e.g., net_convert, trip_generate) while many utility and editing tools include it (e.g., edge_edit_tool, xml_to_sqlite_tool). This mix of naming conventions slightly reduces predictability.
Tool Count3/5
With 26 tools, the server is quite extensive for a single domain. While each tool has a clear role, the count feels high for an MCP server, potentially overwhelming agents. A more focused set (e.g., 15-20 tools) might be more manageable.
Completeness5/5
The tool set covers the entire simulation workflow: data extraction, network conversion, demand generation (with multiple modes), routing, simulation execution, network editing (edges, lanes, speed, TLS), vehicle type editing, analysis (route, road details, SQL database), visualization, reporting, and web search. There are no obvious gaps for the stated purpose of traffic simulation with SUMO.
Average 4.3/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on June 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions running an external script and generating an XML file but omits details like potential side effects, execution time, or permissions. It does not disclose whether input files are modified.
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 with a single line of purpose followed by a bullet list of arguments. It is efficient with no redundant information, though the structure could be slightly improved by merging into a paragraph.
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 tool runs an external script and generates output, the description is incomplete. It does not explain what the generated XML file contains, dependencies (e.g., SUMO installation), or any side effects. Lack of output schema also reduces 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%, so the description must add meaning. It provides brief context for each parameter (e.g., tag extraction for net_file, output directory for results). However, it lacks format constraints or further explanation, leaving gaps for a 3-parameter tool.
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 states it runs a SUMO script to optimize traffic light offsets and generate an XML file. The verb 'optimize' and resource 'traffic light offsets' are clear, but it doesn't explicitly distinguish from the sibling tls_adaptation_tool, which may have overlapping 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?
No guidance on when to use this tool versus alternatives (e.g., tls_adaptation_tool). Prerequisites or context (e.g., after route generation) are not mentioned.
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 must fully disclose behavior. It states the tool reassigns vehicle types but does not indicate whether the input file is modified in place, whether it produces output files (though 'output_dir' implies output), or any side effects. No mention of required permissions, data formats, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line purpose plus parameter list) without extraneous text. It front-loads the purpose. However, as a result it omits necessary detail, so it could be slightly longer to improve completeness without losing conciseness.
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 3 parameters, no output schema, and no annotations, the description is too brief. It does not explain the output file structure, whether multiple files are generated, or how electric_ratio is applied (e.g., stochastic assignment?). A user would need to infer or test behavior. Completeness is low given the complexity.
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%, so the description must add meaning beyond parameter titles. The description lists the parameters but only adds a bit of context: electric_ratio gets a range ('0.0 to 1.0') which is not in schema. route_file and output_dir merely repeat the parameter titles. This is marginally helpful but insufficient to fully understand parameter usage.
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 states the action ('reassign vehicle types') and the data source ('route file') and the criterion ('electric_ratio'). It clearly distinguishes from sibling editing tools like edge_edit_tool or speed_limit_edit_tool. However, it lacks specificity on what 'reassign' entails (e.g., modifies file or creates new one) and the exact nature of the output.
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 like vehicle_generation_tool or flow_generation_tool. No conditions, prerequisites, or exclusions are mentioned. The agent must infer usage from 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, the description carries full burden but provides minimal behavioral detail. It only states the tool runs a script and generates output, omitting side effects, error conditions, permissions, or performance considerations.
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 one-sentence purpose followed by a clear Args list. It is front-loaded and avoids unnecessary 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?
The description lacks important context: no output schema, no description of the generated XML file's name or content, no mention of system dependencies (SUMO), and no error handling information. This is insufficient for an agent to safely invoke the tool.
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 brief explanations for each parameter beyond the schema titles (e.g., 'tag will be extracted from filename' for net_file). However, it does not elaborate on constraints, default behavior, or format requirements, and schema coverage is 0%.
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 explicitly states it runs a specific script (tlsCycleAdaptation.py) to optimize traffic light cycles and generates an XML file. This clearly identifies the verb and resource, and distinguishes it from sibling tools like tls_offset_tool.
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. It does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool visualizes and saves a PNG, but fails to mention whether it is read-only, modifies any files, requires network connectivity, or has side effects like creating directories. The destructive hint and read-only hint are absent, leaving the agent unsure of safety.
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 (6 lines) with a clear hierarchy: single-sentence purpose, usage warning, and parameter list. Every sentence adds value, and the warning is front-loaded for quick agent comprehension.
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 no output schema and 0% schema coverage, the description should provide more context about the tool's output (e.g., file path or success message) and error handling. While it covers usage and parameters, it omits result details, making it incomplete for an agent to understand the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (only titles), so the description's Args section adds crucial meaning: it clarifies that net_file expects a '.net.xml' path and output_dir is the directory for visualization files. This fills a significant gap, though it doesn't explain the default behavior of output_dir.
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 ('Visualize a SUMO network file and save as PNG image'), specifying the resource as a SUMO network file. While it doesn't explicitly differentiate from sibling visualization tools like visualize_edge_tool, the tool name ('net_tool') and the focus on 'network file' provide adequate distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, actionable guidance: 'Only use when user EXPLICITLY requests visualization!' with concrete examples of when to use ('show network map', 'visualize network') and when not to use ('questions about simulation results'). This is exemplary for guiding an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool highlights edges and saves a PNG, which implies file creation, but does not mention side effects like overwriting behavior, required file permissions, or whether the network file is modified. Basic transparency, but missing details.
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 front-loaded with the purpose, followed by bullet-point usage guidelines and an args list. It is relatively concise, though the args section is somewhat redundant with the schema (justified by lack of schema descriptions). Minor room for trimming.
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 3 parameters, no output schema, and no annotations, the description covers the basics: what it does, when to use, and parameter meanings. However, it omits output file naming, return value (if any), and prerequisites (e.g., net_file must exist). Incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's Args section adds one-line explanations for all three parameters (net_file, road_name, output_dir), which adds meaning beyond the schema. However, the descriptions are minimal (e.g., road_name format not specified), so not a perfect 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 'Visualize a SUMO network file with selected edges highlighted and save as PNG image,' providing a specific verb and resource. However, it does not explicitly differentiate between sibling tools like visualize_edgedata_tool or visualize_net_tool, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with examples of when to use ('show edge details', 'visualize this road') and when not to use ('which road is congested?' → answer with text). This strongly aids the agent in correct invocation.
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. It states that routes are assigned using shortest-path and that the output is a .rou.xml file. It does not disclose potential side effects, resource usage, or error conditions. Basic behavioral traits are implied but 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 concise, well-structured with sections for step context, parameters, and returns. Every sentence adds value without redundancy. The workflow markers are efficient.
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 role in a pipeline, the description adequately covers purpose, parameters, and return value. It connects to sibling tools. The only gap is the undocumented output_dir parameter. The presence of an output schema (context signal) does not affect the score as it is not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains net_file and trip_file with provenance (from net_convert and trip_generate). The third parameter output_dir is not mentioned, though it has a default. The description adds meaningful context beyond the schema, but missing one parameter prevents a higher score.
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 explicitly states 'Generate routes from trips using SUMO's duarouter' and explains the conversion from trips.xml to routes.rou.xml. It distinguishes the tool from siblings by referencing the workflow steps (trip_generate and sumo_runner).
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 workflow context: 'Previous step: trip_generate()' and 'Next step: sumo_runner()'. This tells the agent when to use the tool. However, it does not explicitly mention alternatives or scenarios where the tool should not be used.
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?
Discloses conversion details (road type filtering, UTM projection) and consequence of omitting bbox (roads extending beyond area). No annotations are provided, so description carries the burden, but it omits side effects like file overwriting or error scenarios.
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?
Well-structured with clear sections (step, description, parameters, returns). Every sentence adds value, though some could be merged. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers pipeline context, parameter usage, and return value. Given the tool's moderate complexity and presence of output schema, the description is complete enough for agent use. Missing error handling or performance notes, but not critical.
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%, but the description compensates with a dedicated PARAMETERS section explaining osm_file, city_en, and bbox. output_dir is not explained, though it has a default. Overall, adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts OSM data to SUMO network format, identifies its role as step 2/5, and distinguishes it from sibling tools like osm_extract and trip_generate.
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 explicit pipeline context (previous/next steps), explains when to use bbox parameter (to trim roads), and mentions auto-derivation for city_en. However, it lacks explicit guidance on when to avoid using this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions capturing frames and returning files and execution time, but does not discuss computational cost, potential side effects, or required permissions. The description adds some context but lacks depth for a simulation 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 structured with sections for purpose, execution, parameters, and returns. It is fairly concise given the complexity, though it could be slightly tighter by removing redundancy in parameter descriptions.
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 7 parameters, no schema descriptions, and no output schema, the description is quite complete. It explains each parameter, lists return values, and even advises on next steps. The only missing piece is the output_dir parameter explanation and more detail on return file formats.
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 compensates by explaining each parameter's purpose, format, and relationships (e.g., route_file preferred over trip_file). However, the output_dir parameter is not described in the description, which is a minor 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 'Run SUMO traffic simulation using TraCI' with a specific verb and resource. It distinguishes from sibling tools which are preprocessing or analysis, as no other sibling runs the simulation.
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 indicates the previous step (route_generate()) and provides guidance on when to use route_file vs trip_file. It implies usage as the final simulation step but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that edges still exist and only lane count changes, that trip files can be reused, and provides examples of reduction behavior. However, it does not disclose what happens if reduce_by exceeds existing lanes, whether the operation is reversible, or any resource/permission requirements.
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 sections, bullet points, and examples, making it easy to scan. It is detailed but not excessively verbose. The examples are particularly helpful. However, the length could be slightly reduced by merging some duplicate points (e.g., the workflow note appears twice).
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?
The description covers usage and modes well but lacks information about the output (e.g., what files are produced, return value). With no output schema, the agent may not know what to expect after invocation. Error handling or edge cases (e.g., invalid road name, insufficient lanes) are also not addressed.
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?
Despite 0% schema coverage, the description adds significant meaning: it explains reduce_by and remain_lanes with examples, gives default for output_dir, and clarifies optional parameters like route_file (can be reused). However, some parameters like edge_ids and route_file receive minimal explanation beyond the args list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reduce lanes on road segments' and distinguishes between two modes (relative and absolute). It is specific about the resource (road segments) and verb (reduce lanes), and the context of sibling tools (e.g., edge_edit_tool, speed_limit_edit_tool) implies this is unique for lane reduction.
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 context: it recommends Mode 1 over Mode 2, suggests using reference_location and radius_km for localized reduction, and gives a workflow hint (reduce_lanes → sumo_runner with reusable trip file). However, it does not explicitly state when NOT to use this tool (e.g., if lanes cannot be reduced below 1) or provide alternatives beyond the workflow suggestion.
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 states the tool is read-only (search, look up) and returns a list of results, but does not disclose potential rate limits, authentication needs, or that it does not modify any state. For a search tool, this is acceptable but not exhaustive.
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 (about 10 lines) with a clear structure: purpose sentence, bullet list of use cases, then Args and Returns. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details the return format (list with title, url, snippet). It provides sufficient context for an AI agent to decide when to use this tool versus siblings. Missing explicit mention of search engine limitations or privacy, but adequate overall.
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%, yet the description adds meaningful explanations: 'query: Search query string. Be specific for better results.' and 'max_results: Number of results to return (default: 5, max: 10)'. This compensates well for the lack of schema descriptions.
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 explicitly states the verb 'search', the resource 'the web using DuckDuckGo', and the context 'simulation scenario design'. It lists specific use cases (venue capacity, geographic info, traffic patterns) which clearly distinguish it from sibling tools that are all simulation-related.
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 when-to-use guidance with specific examples (venue capacity, geographic info, etc.) and advises on query specificity. However, it does not explicitly state when NOT to use it, though the context of sibling tools implies it is only for external factual lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently describes what the tool does (generates trips, not routes), mentions column mapping, and lists return values (trip_file, trip_count). It could be improved by noting potential errors or performance considerations, but it is generally clear.
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 relatively long but well-structured with sections (modes, column mapping, returns). It is front-loaded with the purpose and then goes into details. It could be slightly more concise, but the structure aids readability.
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 8 parameters (2 required) and an output schema, the description is fairly complete. It explains modes, column mapping, return values, and workflow steps. It could include default values for output_dir or clarify that net_file must come from net_convert, but overall it is 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?
Schema description coverage is 0%, but the tool description explains 6 out of 8 parameters in detail: traffic_condition with values, column_mapping with examples, od_type, trip_type, od_data_file, zone_shp_file. It adds meaning beyond the schema by explaining default columns and mapping keys. However, net_file and output_dir are not explained, and output_dir's default is only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate trip demand (trips.xml) for SUMO simulation' and distinguishes from sibling tool route_generate by explaining that route assignment is done separately. It also breaks down three distinct modes with specific use cases, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: previous step net_convert, next step route_generate. It explains when to use each of the three modes (RandomOD, RealOD-coordinate, RealOD-zone). However, it does not explicitly state when NOT to use this tool or mention alternatives beyond route_generate.
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?
The description discloses key behaviors like coordinate validation and error messages, but it does not mention whether files are created or overwritten, or any side effects. With no annotations, the description carries the full burden, and it falls short of fully disclosing behavioral traits.
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 well-structured with clear sections (purpose, modes, important notes, args, examples). It is front-loaded with the core purpose and efficiently uses bullet points and code blocks. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, two modes, no output schema) and lack of annotations, the description is remarkably complete. It covers modes, parameters, validation, examples, and error handling, making it fully actionable for an AI agent.
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?
Since the input schema has 0% description coverage, the description effectively explains all parameters with defaults, meanings, and examples. It provides clear semantics for complex parameters like use_geocoding and search_radius, enabling correct 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's purpose: 'Add vehicles from source to destination with optimal path calculation.' It then elaborates with two distinct modes (Road Name and Location), making it easy to understand the tool's unique functionality relative to sibling tools.
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 when to use each mode (e.g., 'Location Mode (Recommended)') and offers important notes on validation and error handling. However, it lacks direct comparisons with sibling tools, leaving some ambiguity about when alternatives might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool analyzes road details and returns a dictionary with segments, statistics, and summary. It is clear that the tool is read-only and non-destructive.
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 sections for description, use cases, args, returns, and example. It is slightly verbose, but every sentence adds value. A bit more conciseness could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no output schema), the description is remarkably complete. It explains all parameters, return values, and provides a comprehensive example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides detailed parameter explanations in the Args section, including types, examples, and defaults. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes detailed road information such as lanes, speed limits, length, and provides comprehensive analysis including segments and statistics. It distinguishes itself from sibling tools like 'edge_edit_tool' by focusing on analysis rather than modification.
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 three specific use cases and an example, giving clear context for when to use the tool. However, it does not explicitly state when not to use or mention alternatives, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors such as geocoding usage, safety parameter defaults, and the chaining mechanism. However, it does not specify the return value or output format, which is a gap given no output schema. Overall, it provides good transparency for inputs and internal 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 well-organized with sections (purpose, modes, safety, chaining, parameters, examples). Each sentence adds value, and the structure allows quick scanning. It is appropriately sized for the tool's complexity.
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 (16 parameters, no output schema, no annotations), the description covers most aspects including parameter roles and chaining. It lacks explicit mention of the return value and error handling, but overall it is sufficiently complete for an AI agent to use effectively.
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?
With 0% schema description coverage, the description compensates excellently by explaining each parameter in the 'Args:' block, including defaults, mutual exclusivity, and usage in examples. It adds significant meaning beyond the bare schema definitions.
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 generates a SUMO flow from source to destination, distinguishing two location modes and two vehicle count modes. It is specific about the resource (SUMO flow) and operation (generate), effectively differentiating from sibling tools like trip_generate or route_generate.
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 how to specify locations (place names vs coordinates) and vehicle count (vehs_per_hour vs number), including when to use coordinate mode. It also explains chaining for multi-OD scenarios. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns all edge segments for a road name, raises ValueError if not found, and returns a list of strings. It does not mention side effects or authentication, but for a read-only mapping tool, this is sufficient. The description is transparent about core behaviors.
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 sections (title, important note, args, returns, example workflow, note). The example workflow is detailed but useful. It could be slightly more concise, but every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is thorough: explains both parameters, return type, error handling, and provides a full workflow showing integration with other tools (DB queries, read_query). It gives the agent all necessary context for correct invocation.
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. For 'road_name', it provides examples like '테헤란로' and states it's a road name. For 'net_file', it explains the network file path and gives a specific SQL query to retrieve it from the DB. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Convert road name to SUMO edge IDs using edge.getName().' It explains the mapping from human-readable road names to technical edge IDs, and distinguishes itself from sibling tools like get_road_names_tool by focusing on conversion rather than listing names.
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 explicitly says 'Use this when user asks questions with road names' and provides a complete example workflow showing exactly how and when to use the tool. It lacks an explicit statement of when not to use it or mention of alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return values: 'edge count, junction count, total road length, bounding box, and road name list.' It implies read-only behavior (summary) and does not hide side effects. It could mention file validity requirements, but overall transparent.
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: three short paragraphs. The first sentence states the purpose, the second gives usage guidance, and the third lists arguments and returns. Every sentence adds value; no redundant or vague wording.
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 tool is simple (1 parameter, no output schema), and the description covers its purpose, usage, input, and output. It could mention that the net_file must exist and be valid, but that is implicit. For a lightweight summary tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by stating 'Path to the SUMO network file (.net.xml)' for the single parameter net_file, clarifying it is a file path and specifying the expected format. This goes beyond the schema's bare type 'string'.
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: 'Get a comprehensive summary of a SUMO network.' It specifies the verb 'Get' and the resource 'comprehensive summary of a SUMO network.' The usage guidance explicitly says 'Use when user asks about the network, its size, or what roads are included,' distinguishing it from sibling tools like visualize_net_tool or get_road_names_tool.
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 when-to-use guidance: 'Use when user asks about the network, its size, or what roads are included.' While it does not explicitly list when not to use or alternatives, the context of sibling tools makes it clear that this tool is for summaries, not for conversion or visualization.
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 bears full burden. It discloses that the tool downloads/extracts raw OSM data, returns osm_file, bbox, and tag, and describes the pipeline. It doesn't mention destructive actions, authentication, or rate limits, but these are less relevant for a simulation data extraction 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 slightly verbose with some redundancy (pipeline context appears twice), but it is well-structured with sections and front-loaded with the step number and purpose. Every section adds value, though some trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, multiple area specification methods), the description is thorough. It explains return values, pipeline context, examples, and parameter dependencies. The output schema is provided, so return values are clear.
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 adds extensive meaning: it explains all area specification methods, required/optional parameters, usage examples, and purpose of each parameter. This compensates fully for the lack of schema descriptions.
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 extracts OSM road network data for a given area and is the first step in the simulation pipeline. It distinguishes itself from siblings by referencing next steps like net_convert and providing a pipeline context, making the purpose specific and differentiated.
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 a detailed priority order for area specification (bbox, od_data_file, zone_shp_file, city+radius) with examples, indicating when each method is appropriate. While it doesn't explicitly state when not to use the tool, the context of being the first pipeline step implies usage conditions.
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. Describes that it uses SUMO's standard plot_net_selection.py, shows only selected segments, and returns a PNG. Implies non-destructive behavior, but does not explicitly state it does not modify the network. Minor gap.
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?
Description is somewhat lengthy but well-structured with sections (purpose, usage, visualization details, use cases, workflow, args, returns, example). Each section adds value, and the purpose is front-loaded. Could be slightly trimmed without losing clarity.
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 5 parameters, 0% schema coverage, no output schema, and multiple sibling visualization tools, the description covers purpose, usage, parameters, return type, and example. Lacks error/performance info but is complete for typical use. Adequate for selecting and invoking the 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% (all parameters have no descriptions), but the description adds meaning to each parameter through use cases, example, and explanation (e.g., radius_km in km, reference_location as reference point). The example shows how to call the tool, compensating for schema deficiency.
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 visualizes policy target area using SUMO's built-in visualization, distinguishes from siblings (e.g., visualize_net_tool) by specifying it shows only selected road segments within a radius, and provides a specific verb+resource combo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user explicitly requests to preview policy area) and when not to use (do not use if user just wants to apply policy). Provides a realistic workflow with steps, making it clear when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool maps edge IDs to road names, returns 'Unnamed Road' if not set, and provides example inputs/outputs. However, it does not mention authorization needs or whether it modifies data (it appears read-only, but not stated).
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 well-structured, starting with a clear purpose, then an important note, parameter details, return info, and an example workflow. Every sentence adds value; no extraneous content. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no output schema, the description fully covers its usage: explains both parameters, return format (dict mapping), provides a detailed workflow example, and notes the 'Unnamed Road' behavior. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains edge_ids as 'List of SUMO edge IDs to convert' with examples, and net_file as 'Network file path used in simulation' with a SQL hint for DB users. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Convert SUMO edge IDs to actual road names using edge.getName().' It clearly defines the tool's purpose as mapping technical edge IDs to human-readable names, distinguishing it from siblings like get_edge_ids_from_road_name_tool which does the reverse.
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 includes an 'IMPORTANT' note stating 'Use this after congestion analysis to show human-readable road names!' providing clear context for when to use the tool. It also gives an example workflow showing its role after data queries, but does not explicitly exclude alternative 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?
Discloses non-destructive behavior: 'Trip file can be reused - edges still exist, only speed limit changed.' No annotations provided, so description carries burden. Could mention if modifications are reversible or output file location, but overall transparency is good.
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?
Well-structured with sections: workflow, realistic usage, examples, and Args list. Front-loaded with purpose. Every sentence adds value, no fluff. Appropriate length for a complex tool.
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?
Covers main use cases, workflow, and parameter details. With 8 parameters and no output schema, description provides enough context for typical usage. However, it could explicitly mention what the tool outputs (e.g., modified net file) to be fully complete.
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 has 0% description coverage, but description adds brief yet useful parameter explanations with example values (e.g., reference_location='강남역'). Clarifies optionality and usage for all parameters, compensating for schema gaps.
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?
Explicitly states 'Modify speed limits on specific road segments' with a specific verb and resource. Distinguishes from siblings like edge_edit_tool by focusing on speed limits and mentioning partial application and reuse of trip files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear workflow (speed_limit_edit → sumo_runner) and realistic usage advice (use reference_location and radius_km). Examples show how to call the tool and interpret parameters. Explicitly states when to reuse trip file, guiding against unnecessary regeneration.
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, but the description details the tool's behavior: it validates coordinates, returns network inclusion status, nearest edge, and distance. It does not disclose side effects, but as a validation tool it is likely read-only. The description is comprehensive.
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 well-structured with clear sections (Args, Returns, Example), front-loaded purpose, and no unnecessary sentences. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description fully explains input format, output structure, and provides an example. It leaves no gaps for an agent to use the tool correctly.
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%, but the description thoroughly documents all parameters: net_file (SUMO network file), coordinates (list of dicts with lat, lon, label), and search_radius (default 0.5 km). It adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates coordinates against a SUMO network, checks network inclusion, and finds nearest edges. The verb 'validate' with resource 'coordinates' is specific, and it distinguishes from siblings by stating 'Use this BEFORE generating flows'.
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 'Use this BEFORE generating flows' and 'Essential for agentic OD planning', providing clear context. No when-not-to-use or alternatives are mentioned, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that distance mode works without simulation data, and traveltime requires weight_file. It also describes return format and web visualization marker. Could be improved by explicitly stating no side effects or limitations.
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 sections, but somewhat long. However, given the tool's complexity (8 parameters, two modes, comparison feature), all content is necessary and front-loaded. Minor redundancy could be trimmed, but overall efficient.
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?
Despite no output schema, the description describes the return dict (route edges, distance, time, road names) and comparison results. It covers all parameters, modes, and special instructions for web mode, making the tool fully understandable without additional context.
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%, but the description adds extensive meaning to all 8 parameters: explains defaults, required vs optional, formats, and usage context (e.g., weight_file required when routing_mode='traveltime'). This fully compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing optimal routes between two locations. It specifies input types (place names, road names) and two routing modes (distance and traveltime), distinguishing it from sibling tools like network_summary_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases with examples, explains when to use each routing mode, and mentions comparison scenarios. Includes guidance for web mode marker, making it easy for an agent to decide when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains scale modes and parameters clearly, but does not explicitly state whether the tool is read-only or any side effects. However, as a visualization tool, this is reasonable.
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?
Well-structured with sections, but slightly verbose due to repeated examples. Front-loaded with purpose and warnings. Every part is justified.
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?
With 8 parameters, no output schema, and no annotations, the description provides comprehensive coverage: all parameters explained, use cases, scale modes, and examples. It fully compensates for the lack of structured metadata.
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%, but the description's 'Args' section explains all 8 parameters with context, default values, and examples. This adds significant meaning beyond the schema's bare 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 it visualizes SUMO edgedata with flexible scaling modes. It distinguishes from siblings like visualize_net_tool by explicitly focusing on edgedata and visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (user requests heatmap/visualization) and when-not-to-use (answer textually to 'which road is congested?'), with alternative approaches. Also includes use cases for each scale mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses the database schema, table structures, keys, and design philosophy. Warns about table name 'edge_metrics' not 'edgedata'. Describes return format and provides examples.
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-organized with sections (IMPORTANT, DATABASE SCHEMA, ROAD-LEVEL ANALYSIS, Args, Returns, Examples) but is quite lengthy. Every section adds value, but it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is highly complete. It covers schema, SQL examples, parameter details, usage guidelines, and references to sibling tools.
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 description must compensate. It thoroughly explains each parameter: tripinfo_xml, edgedata_xml, etc., including format, required values, and important notes. Provides formatting examples for simulation_id and 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?
The description clearly states the tool's purpose: 'Convert SUMO XML results to SQLite database for advanced SQL-based analysis.' It distinguishes from siblings by emphasizing SQL-based queries and explicitly stating that road-level analysis does not require get_edge_ids_from_road_name_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidelines: for advanced queries beyond summary statistics. Gives examples of query types. Warns about required parameters (simulation_id and description must never be None). Explicitly tells when not to use a sibling tool: 'NO need for get_edge_ids_from_road_name_tool!'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully compensates by disclosing critical behavior: deletion invalidates route files, requires rerun of trip_generate, and returns requires_reroute=True. Includes clear warnings and workflow 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?
Well-organized with bold warnings, sections for modes, bulleted examples, and parameter list. Every sentence adds value without redundancy. Critical information is front-loaded.
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?
Despite 7 parameters and no output schema, the description covers all necessary context: modes, prerequisites, workflow, example outputs, and return value indicating required rerun. Completely sufficient for correct tool invocation.
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. The description explains all 7 parameters, including defaults, optionality, and usage in different modes. Examples illustrate parameter combinations for realistic and extreme scenarios.
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 states 'Delete specific road segments from the network file' with three distinct modes (edge_ids, target_road_name+location+radius, target_road_name only), clearly distinguishing use cases. It includes realistic examples and contrasts with extreme scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use each mode (priority order) and realistic vs extreme use. Warns that after deletion, trips and routes must be regenerated, and specifies the workflow: edge_edit → trip_generate → route_generate → sumo_runner.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: it generates a standalone dark-themed HTML file with KPIs, comparisons, congestion analysis, and emissions. It also describes output usage (view in web interface, browser, share). No contradictions.
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 well-structured with a title, overview, bullet-point prerequisites, and args/returns section. It is concise yet comprehensive, with no redundant information. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return type (dict with file path and metadata) and the report's nature (HTML, dark-themed). It covers all aspects: input requirements, output, and file characteristics. The tool is a simple reporting tool, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes an 'Args' section with clear explanations for each parameter: db_path (path to database), executive_summary (LLM-generated summary with specific content), output_dir (output directory with default). This adds significant meaning beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it generates a comprehensive HTML simulation analysis report from SQLite database, which is a specific verb+resource. It distinguishes itself from sibling tools like visualize_* and analysis tools by being the final deliverable summarizing all scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an 'IMPORTANT' section detailing prerequisites: query the database and write an executive summary before calling the tool. This clearly guides when and how to use the tool, making it the final step in analysis.
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:

[![kra35-prismx-agentsumo MCP server](https://glama.ai/mcp/servers/urban-ai-institute/kra35-prismx-agentsumo/badges/card.svg)](https://glama.ai/mcp/servers/urban-ai-institute/kra35-prismx-agentsumo)

Score Badge

Copy to your README.md:

[![kra35-prismx-agentsumo MCP server](https://glama.ai/mcp/servers/urban-ai-institute/kra35-prismx-agentsumo/badges/score.svg)](https://glama.ai/mcp/servers/urban-ai-institute/kra35-prismx-agentsumo)

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/urban-ai-institute/kra35-prismx-agentsumo'

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