BULC Building Designer

by using76

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as separate tools for creating, modifying, listing, and deleting different entities (rooms, walls, furniture, meshes). However, some overlap exists in evacuation-related tools (e.g., bulc_get_evac_result, bulc_get_evac_summary, bulc_load_evac_result) where the distinctions are subtle but clarified by descriptions.
Naming Consistency5/5
All tools follow a consistent 'bulc_verb_noun' pattern with snake_case, making them predictable and readable. The naming convention is uniform across all 75 tools, with verbs like create, get, list, set, run, and modify used consistently for similar operations.
Tool Count2/5
With 75 tools, the set is excessively large for a building design and fire simulation server, leading to potential overwhelm and redundancy. While the domain is complex, many tools could be consolidated (e.g., multiple evacuation result tools) or parameterized to reduce count without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for building design, fire dynamics simulation (FDS), and evacuation analysis, including full CRUD operations for rooms, walls, furniture, and meshes, plus simulation setup, execution, monitoring, and result analysis. No obvious gaps are present for the intended domain.
Average 3.7/5 across 75 of 75 tools scored. Lowest: 3.1/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 status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true), which the description doesn't explicitly state. The description adds context about what properties can be modified, but doesn't disclose behavioral traits like whether changes are reversible, if there are validation constraints, or what happens to dependent data. No contradiction with annotations exists.
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, efficient sentence that front-loads the core action. It avoids unnecessary words, though it could be slightly more structured by explicitly listing key properties. Every part of the sentence contributes to understanding the tool's purpose.
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 destructive modification tool with 10 parameters and no output schema, the description is insufficient. It lacks critical context such as what 'other properties' entails, validation rules, error conditions, or expected outcomes. Annotations cover safety but don't compensate for the missing behavioral and output details needed for effective use.
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 100% schema description coverage, the input schema fully documents all 10 parameters. The description mentions 'dimensions' and 'cell counts', which map to parameters like xMin/xMax and iCells, but adds no additional semantic context beyond what's in the schema (e.g., units, constraints, or relationships between parameters).
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 ('Modify') and resource ('existing FDS mesh'), and specifies what can be changed ('dimensions, cell counts, or other properties'). It distinguishes from creation tools like 'bulc_create_mesh' by focusing on modification, but doesn't explicitly differentiate from other modification tools like 'bulc_modify_room' or 'bulc_modify_wall'.
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 mesh), exclusions (e.g., not for creating new meshes), or comparisons with sibling tools like 'bulc_auto_mesh' for automated mesh generation or 'bulc_delete_mesh' for removal.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating this is a write operation with destructive potential. The description adds context about what gets generated (analysis reports) but doesn't elaborate on what 'destructive' means in this context (e.g., overwriting files, modifying data). No rate limits, authentication needs, or specific behavioral traits are mentioned.
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 - one sentence that states the core purpose and lists supported report types. No wasted words, though it could be slightly more structured by separating purpose from capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 100% schema coverage, and clear annotations, the description provides adequate context about what the tool does. However, as a destructive operation with no output schema, it could benefit from more detail about what gets created/destroyed and what the output looks like. The lack of differentiation from the sibling RSET-specific tool is a notable gap.
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 100% schema description coverage, all parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions (e.g., explaining what ASET/RSET reports contain, what graphs/slices show). The baseline of 3 is appropriate when the schema does the heavy lifting.
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 ('generate') and resource ('analysis report from FDS simulation results'), and specifies the supported report types (ASET, RSET, combined). However, it doesn't explicitly differentiate from sibling 'bulc_generate_rset_report', which appears to be a more specific version of this 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 about when to use this tool versus alternatives. The description mentions three report types but doesn't explain when to choose each type or what prerequisites exist (e.g., needing simulation results first). There's no mention of the sibling 'bulc_generate_rset_report' tool.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the data types returned (slices, smoke3d volumes, etc.), which isn't covered by annotations. However, it doesn't disclose other behavioral traits like potential rate limits, error conditions, or whether it requires specific permissions beyond having loaded results. No contradiction with annotations exists.
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 and front-loaded, stating the main purpose in the first clause. The second clause adds useful detail about return types without redundancy. It's efficient with two sentences, though it could be slightly more structured by explicitly mentioning the optional filtering parameter upfront.
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 optional parameter, no output schema), the description is somewhat complete but has gaps. It covers the purpose and return types, but lacks usage guidelines and detailed behavioral context. With annotations covering safety, it's adequate for a simple read operation, but could benefit from more context about when and how to use it effectively.
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 input schema has 100% description coverage, with a clear enum for the 'type' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, such as default behavior details or examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily supplement the 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 tool's purpose: 'List available datasets in the loaded FDS results.' It specifies the verb ('List') and resource ('datasets in the loaded FDS results'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'bulc_get_fds_data' or 'bulc_get_point_data', which might also retrieve data, so it doesn't reach 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 mentions the types of data returned (slices, smoke3d volumes, etc.), but doesn't specify prerequisites (e.g., requires loaded FDS results) or compare it to other data-fetching tools in the sibling list, such as 'bulc_get_fds_data' or 'bulc_get_point_data'. This leaves the agent without clear usage context.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a mutating operation. The description adds context by specifying detector types (heat/smoke) and their parameters, but doesn't elaborate on destructive effects (e.g., overwrites existing detector settings) or other behavioral traits like error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and key details. It avoids redundancy and is appropriately sized for the tool's complexity, though it could be slightly more structured by separating heat and smoke specifics.
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 complexity (8 parameters, destructive mutation) and lack of output schema, the description is moderately complete. It covers detector types but lacks details on return values, error conditions, or integration with other FDS tools, leaving gaps for an AI agent to infer usage.
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 100%, so parameters are fully documented in the schema. The description adds minimal value by mentioning RTI and activation temperature for heat detectors, and obscuration threshold for smoke detectors, but doesn't provide additional semantics beyond what the schema already covers.
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 ('Configure') and resource ('a furniture item as an FDS detector'), specifying it can be heat or smoke detectors. It distinguishes from siblings like 'bulc_place_furniture' (creation) and 'bulc_modify_furniture' (general modification), but doesn't explicitly mention these alternatives.
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 is provided. It doesn't mention prerequisites (e.g., furniture must exist), when not to use it, or compare to similar tools like 'bulc_set_fds_sprinkler' or 'bulc_set_fds_thermocouple' for other FDS configurations.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating a non-read-only, potentially destructive operation. The description adds value by specifying what gets configured (slice files, 3D smoke, device output intervals), which helps the agent understand the scope of changes. However, it doesn't disclose additional behavioral traits like side effects, permissions needed, or rate limits beyond what annotations provide.
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 efficiently state the purpose and key controls. It's front-loaded with the main action ('Configure FDS output settings') and avoids unnecessary details. However, the second sentence could be slightly more structured by listing the controls more clearly.
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 complexity (6 parameters, destructive operation) and rich schema coverage (100%), the description is adequate but incomplete. It lacks output information (no output schema provided) and doesn't cover error conditions or side effects. The annotations help, but for a destructive configuration tool, more context on impact or dependencies would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented in the input schema (e.g., intervals in seconds, boolean flags). The description adds minimal value beyond the schema by naming the parameter categories (slice files, 3D smoke, device output) but doesn't explain parameter interactions or provide additional context. Baseline 3 is appropriate since the schema does the heavy lifting.
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 as 'Configure FDS output settings for visualization data' with specific resource (FDS output settings) and verb (configure). It distinguishes from siblings by focusing on output intervals for visualization, unlike tools for mesh creation or simulation control. However, it doesn't explicitly differentiate from other configuration tools like bulc_set_fds_detector or bulc_set_fds_sprinkler.
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 active simulation), exclusions (e.g., not for input settings), or suggest other tools for related tasks. The context is implied through 'visualization data' but lacks explicit usage instructions.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds minimal behavioral context beyond this - it clarifies the scope ('room or all rooms') but doesn't mention side effects, permissions needed, or what happens to cleared agents. With annotations covering the safety profile, a 3 is appropriate.
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 immediately communicates the core functionality. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with good annotations but no output schema, the description is minimally adequate. It covers what the tool does but lacks important context about consequences, timing, or relationships to other tools in the evacuation workflow. The annotations help but don't fully compensate for the description's gaps.
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 100%, with both parameters ('room' and 'level') well-documented in the schema. The description implies the 'room' parameter's optional nature ('Omit to clear all') but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is correct when schema does the heavy lifting.
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 ('clear evacuation agents') and target ('from specified room or all rooms'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'bulc_list_evac_agents' or 'bulc_place_evac_agents', which would require 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 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, timing considerations, or relationships to other tools like 'bulc_list_evac_agents' (for viewing agents) or 'bulc_place_evac_agents' (for adding them).
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?
Annotations already indicate this is a destructive (destructiveHint: true) and non-read-only (readOnlyHint: false) operation, so the agent knows it's a mutation that removes data. The description adds minimal context by specifying what gets removed ('stair configuration'), but doesn't elaborate on side effects, permissions needed, or what happens if no stair configuration exists. No contradiction with annotations.
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 states the tool's purpose without unnecessary words. It's appropriately sized for a simple operation and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with one parameter and no output schema, the description is minimally adequate. It states what the tool does, but lacks details on behavioral context (e.g., error conditions, what 'clear' means precisely) and doesn't compensate for the absence of an output schema. The annotations help, but more context would be beneficial.
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 100%, with the single parameter 'furnitureId' clearly documented in the schema. The description doesn't add any additional semantic information about the parameter beyond what's in the schema (e.g., format examples, constraints), so it meets the baseline for high schema coverage.
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 ('Remove') and target ('stair configuration from a furniture item'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'bulc_delete_furniture' or 'bulc_modify_furniture', which might also affect furniture items.
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. There are multiple sibling tools that manipulate furniture (e.g., 'bulc_delete_furniture', 'bulc_modify_furniture', 'bulc_place_furniture'), but the description doesn't indicate when clearing stair configuration is appropriate versus deleting or modifying the furniture entirely.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating this is a mutating operation with destructive potential. The description adds useful context about elevation semantics (height from ground in cm, negative for basements) and default placement behavior when elevation is omitted. However, it doesn't elaborate on what 'destructive' means in this context (e.g., whether existing levels are affected) or mention any permissions, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that immediately states the tool's purpose and provides the most critical parameter clarification (elevation definition). Every word earns its place with zero redundancy or fluff. The structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with destructiveHint=true and no output schema, the description is minimally adequate. It explains what gets created and clarifies the most important parameter (elevation), but doesn't address what 'destructive' means in practice, what happens on success/failure, or what the return value might be. Given the complexity of level creation in a building model context, more behavioral context would be helpful.
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 100% schema description coverage, all three parameters are well-documented in the schema itself. The description adds marginal value by clarifying elevation semantics ('height from ground (Z=0) to the floor surface in centimeters') and mentioning the default placement behavior when elevation is omitted. However, it doesn't explain parameter interactions or provide examples beyond what's already in the schema descriptions.
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 ('Create') and resource ('new floor level'), making the purpose immediately understandable. It distinguishes from siblings like 'bulc_create_room' or 'bulc_create_wall' by specifying it creates floor levels rather than other building elements. However, it doesn't explicitly differentiate from 'bulc_list_levels' (which lists existing levels), though the 'create' vs 'list' distinction is implied.
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., whether a building model must exist first), when not to use it, or how it relates to sibling tools like 'bulc_list_levels' or 'bulc_set_current_level'. The agent must infer usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive, non-read-only operation, which the description aligns with by using 'Delete.' However, the description adds minimal behavioral context beyond this—it doesn't specify irreversible effects, permissions required, or error conditions. With annotations covering the safety profile, a baseline 3 is appropriate as the description adds some value but lacks rich behavioral details.
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, direct sentence with no wasted words, efficiently conveying the core action and parameter. It's appropriately sized for a simple tool and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (annotations hint at this), lack of output schema, and simple single parameter, the description is minimally adequate. It covers the basic action but omits important context like what happens post-deletion, error handling, or dependencies on other tools, leaving gaps in 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?
The input schema has 100% description coverage, clearly documenting the single 'meshId' parameter. The description mentions 'by its ID,' which reinforces the parameter's purpose but doesn't add significant semantic details beyond what the schema provides, such as format examples or constraints.
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 ('Delete') and target resource ('an FDS mesh by its ID'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'bulc_delete_room' or 'bulc_delete_wall' beyond specifying the resource type, 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. It doesn't mention prerequisites (e.g., needing a mesh ID from 'bulc_list_meshes'), exclusions, or comparisons to other deletion tools in the sibling list, leaving the agent without contextual usage cues.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying file creation (a write operation). The description adds context about creating supporting files, which isn't covered by annotations, but doesn't detail potential side effects like overwriting existing files or permission requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core action ('Export the FDS input file to disk') and follow with essential details ('Creates the .fds file and any required supporting files'). Every word contributes value without redundancy or fluff.
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 annotations covering safety (destructive), the description adequately explains what the tool does but lacks details on return values, error conditions, or integration with sibling tools. It's minimal but functional for a file export tool, fitting a moderate score.
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 100%, so the schema fully documents parameters like outputPath, filename, and includeGeometry. The description adds no additional parameter semantics beyond implying file creation, which is already covered by the tool's purpose. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 ('Export') and the resource ('FDS input file to disk'), specifying that it creates .fds and supporting files. It distinguishes from siblings like 'bulc_preview_fds' (preview vs. export) and 'bulc_get_fds_data' (retrieve vs. create files), but doesn't explicitly contrast with all siblings, 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, such as 'bulc_preview_fds' for previewing or 'bulc_run_fds' for simulation. It lacks context about prerequisites (e.g., needing an FDS project loaded) or exclusions, offering only basic functional information.
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?
Annotations indicate this is a destructive operation (destructiveHint: true) and not read-only (readOnlyHint: false). The description doesn't contradict these annotations, and it adds context by specifying it generates a report 'from evacuation simulation results', implying it processes existing data. However, it doesn't elaborate on what gets destroyed, whether it overwrites existing files, or any rate limits or authentication requirements beyond what annotations provide.
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 immediately conveys the core functionality without any wasted words. It's front-loaded with the main action ('Generate RSET analysis report') and includes the essential context ('from evacuation simulation results'). Every element earns its place in this compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, and destructive annotations, the description provides adequate but minimal context. It specifies what's being generated (RSET report) and the data source (evacuation simulation results), which is essential. However, without an output schema, it doesn't describe the report format or content, and it lacks guidance on when this tool fits in the workflow relative to other tools like 'bulc_get_evac_result' or 'bulc_generate_report'.
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 100% schema description coverage, all three parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions (output directory, language options, agent details inclusion). This meets the baseline expectation when schema coverage is complete, but doesn't provide extra value like explaining why these parameters matter for RSET reports.
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 'Generate' and the resource 'RSET analysis report', specifying it's created 'from evacuation simulation results'. This distinguishes it from generic report generation tools like 'bulc_generate_report' by focusing on RSET analysis specifically. However, it doesn't explicitly differentiate from other analysis tools like 'bulc_run_aset_analysis' beyond the RSET 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. It doesn't mention prerequisites (like needing evacuation results first), doesn't specify when this should be used instead of other report generation or analysis tools, and offers no context about typical workflow sequencing. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the types of results (trajectories, statistics, analysis), which aren't covered by annotations. However, it doesn't disclose behavioral traits like potential data size, performance implications, or prerequisites (e.g., needing 'bulc_load_evac_result' first). With annotations covering safety, this earns a baseline score for adding some context.
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 front-loads the core purpose ('Get detailed evacuation results') and lists key data types without redundancy. Every word adds value, and there's no unnecessary elaboration or repetition, making it highly concise and well-structured for quick understanding.
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 complexity (retrieving detailed simulation results with 5 parameters) and the absence of an output schema, the description is moderately complete. It outlines the data types returned but doesn't specify output format, size, or how results integrate with other tools (e.g., 'bulc_load_evac_result'). With annotations covering read-only safety, it's adequate but lacks depth for full contextual understanding.
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 100%, with all five parameters well-documented in the input schema (e.g., defaults and purposes). The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining how 'timeRange' interacts with simulation data or the impact of including trajectories. Given high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 ('Get') and the resource ('detailed evacuation results'), specifying three types of data included: per-agent trajectories, exit statistics, and flow rate analysis. It distinguishes from siblings like 'bulc_get_evac_summary' by emphasizing 'detailed' results, though it doesn't explicitly name alternatives. This is specific but lacks direct sibling differentiation.
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 'bulc_get_evac_summary' or 'bulc_get_evac_status'. It doesn't mention prerequisites like needing a completed evacuation simulation or loaded results, nor does it specify contexts where this detailed data is preferred over summaries. This leaves the agent without clear usage cues.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about what data is returned (FDS categories and configuration parameters), which goes beyond the annotations. However, it doesn't describe behavioral aspects like error conditions, performance characteristics, or data format details.
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 perfectly concise - two sentences that efficiently convey the tool's purpose and return values without any wasted words. It's front-loaded with the core functionality and follows with output details, making it easy for an agent 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?
For a read-only tool with good annotations and complete parameter documentation, the description provides adequate context about what data is retrieved. However, without an output schema, the description should ideally provide more detail about the return format (structure, data types, example values) to help the agent understand how to process the response.
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 100% schema description coverage, the input schema fully documents the single required parameter (furnitureId). The description adds no additional parameter semantics beyond what's in the schema, but doesn't need to since schema coverage is complete. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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: 'Get FDS configuration for a furniture item' with specific output details (FDS categories and configuration parameters). It distinguishes from siblings like bulc_clear_fds_data (deletion) and bulc_set_fds_* tools (configuration), but doesn't explicitly name alternatives for similar retrieval operations.
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 implies usage for retrieving FDS configuration, it doesn't mention when to choose this over other data retrieval tools like bulc_get_point_data or bulc_get_fds_status, nor does it specify prerequisites or contextual constraints.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it lists 'all' evacuation agents, implying completeness, but doesn't provide additional behavioral context like pagination, performance characteristics, or data freshness. No contradiction with annotations exists.
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 front-loads the core purpose ('List all evacuation agents') and adds clarifying details ('with their positions and properties'). There is no wasted wording, and it's appropriately sized for a simple list operation.
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 (read-only list operation), rich annotations (readOnlyHint, destructiveHint), and full schema coverage, the description is adequate but minimal. It lacks output details (no output schema provided) and doesn't explain relationships with sibling tools, which could help in tool selection. For a basic list tool, it meets minimum requirements but misses opportunities for fuller context.
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 100%, with both parameters ('level' and 'room') clearly documented in the input schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples or constraints on filtering behavior. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all evacuation agents') and the scope ('with their positions and properties'), which is specific and informative. It distinguishes from some siblings like 'bulc_place_evac_agents' (create) or 'bulc_set_agent_properties' (modify), but could more explicitly differentiate from 'bulc_get_evac_result' or 'bulc_get_evac_summary' which might also retrieve agent data in different contexts.
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 siblings like 'bulc_get_evac_result' or 'bulc_get_evac_summary' that might provide overlapping or complementary evacuation agent information, nor does it specify prerequisites or typical use cases (e.g., for inventory checking vs. simulation analysis).
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context by specifying 'detected' evacuation exits, which implies a retrieval of pre-existing data, but does not disclose details like pagination, rate limits, or error conditions. With annotations covering safety, the description adds some value but lacks rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to parse and understand quickly, with zero wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only operation, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on output format, error handling, or integration with other tools, which could be helpful for an agent in a complex server environment with many siblings.
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 100% for the single parameter 'level', which is documented as 'Filter by floor level'. The description does not add any meaning beyond this, such as format constraints or default behavior. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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 ('List') and resource ('evacuation exits') with the clarifying detail 'doors converted to exits', making the purpose specific. However, it does not explicitly differentiate from sibling tools like 'bulc_list_evac_agents' or 'bulc_list_evac_stairs', which also list evacuation-related items, so it lacks sibling differentiation for 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 other list tools for evacuation components or filtering options. It mentions 'detected' evacuation exits but does not specify prerequisites, exclusions, or contextual usage, leaving the agent without clear direction.
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?
Annotations indicate non-read-only and non-destructive (readOnlyHint=false, destructiveHint=false), suggesting a safe operation. The description adds that it loads results 'for visualization', implying it may trigger a viewer or prepare data for display, which is useful context beyond annotations. However, it doesn't detail side effects like whether it overwrites existing loaded results or requires specific file formats, leaving 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 a single, efficient sentence that front-loads the core action ('Load evacuation results') and purpose ('for visualization'), with no wasted words. It's appropriately sized for a tool with one parameter and clear annotations, 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 one parameter with full schema coverage and annotations covering safety, the description is minimally adequate. However, with no output schema and siblings like visualization-related tools, it could better explain the visualization outcome (e.g., whether it opens a viewer or just loads data). The context is incomplete for understanding the full tool behavior in the ecosystem.
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 100%, with the parameter 'evacPath' fully documented in the schema. The description mentions '.evac file' but doesn't add semantic details beyond what the schema provides (e.g., file format specifics or visualization implications). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with extra parameter insights.
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 ('Load evacuation results') and resource ('.evac file'), with the purpose 'for visualization' adding useful context. It distinguishes from siblings like 'bulc_get_evac_result' (which likely retrieves results without loading for visualization) and 'bulc_open_evac_viewer' (which might open a viewer without loading data). However, it doesn't explicitly contrast with these specific alternatives.
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 siblings like 'bulc_get_evac_result' and 'bulc_open_evac_viewer', the description lacks explicit direction on scenarios favoring this tool, such as loading saved results from a file versus fetching current simulation results. Usage is implied through the file-loading context but not articulated.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, which the description doesn't contradict, as 'Open... viewer window' implies a non-destructive, interactive action. The description adds context about displaying agents and timeline playback, which goes beyond annotations, but it doesn't detail behavioral traits like window management, resource usage, or error handling, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and functionality. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy for an agent to quickly understand the core action.
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 moderate complexity (5 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on integration with other tools, expected outcomes, or error scenarios. With no output schema, it doesn't explain what the viewer returns or how to interact with it post-opening, leaving some contextual gaps.
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 input schema has 100% description coverage, with all parameters well-documented, so the description doesn't need to add parameter details. It doesn't provide additional semantics beyond the schema, such as explaining interactions between parameters or typical use cases, but this is acceptable given the high schema coverage, resulting in a baseline 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 ('Open... viewer window') and what it displays ('Displays agents on the building model with timeline playback'), providing a specific verb and resource. However, it doesn't explicitly differentiate from the sibling 'bulc_open_result_viewer', which might be a related visualization tool, leaving some ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'bulc_open_result_viewer' or other visualization tools in the sibling list. It lacks context about prerequisites, such as needing a completed evacuation simulation, and doesn't mention exclusions or typical workflows, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying overwriting ('saves to current file (overwrites)'). However, the description doesn't add significant behavioral context beyond what annotations provide, such as file format, error conditions, or confirmation 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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, 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?
For a destructive write operation with no output schema, the description is minimally adequate. It covers the basic action but lacks details on success/failure responses, file formats, or integration with other tools, leaving gaps in context given the tool's potential impact.
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 input schema has 100% description coverage, fully documenting the optional 'path' parameter. The description doesn't add any meaningful parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage.
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 ('Save') and resource ('current project to file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'bulc_export_fds' or 'bulc_save_evac_result', which might also involve saving operations to files.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requires an open project), exclusions, or comparisons to other save-related tools in the sibling list.
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?
Annotations provide readOnlyHint=false and destructiveHint=true, indicating a mutable, potentially destructive operation. The description adds context by specifying these are 'default' properties, suggesting they apply to future agents. However, it doesn't clarify what 'destructive' entails (e.g., overwrites existing defaults, affects ongoing simulations). No contradiction with annotations; description supplements but lacks detail on behavioral implications.
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?
Single sentence, front-loaded with the core action ('Set default properties'), followed by illustrative examples. No wasted words; every element ('evacuation agents', 'radius, speed, etc.') contributes to understanding. Efficient and well-structured for quick 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 destructive annotations (no output schema), the description is minimally adequate. It covers the tool's purpose and hints at scope ('default properties'), but lacks details on effects (e.g., whether changes are immediate, reversible, or simulation-dependent). For a destructive tool with rich sibling context, more completeness on impact and integration would be beneficial.
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 100%, with each parameter clearly documented (e.g., 'agentRadius' as 'Default agent radius in meters. Default: 0.25'). The description only generically references 'radius, speed, etc.', adding minimal semantic value beyond the schema. Baseline score of 3 is appropriate since the schema fully defines parameters.
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 ('Set') and target ('default properties for evacuation agents'), with specific examples of properties ('radius, speed, etc.'). It distinguishes from siblings like 'bulc_get_evac_settings' (read) and 'bulc_place_evac_agents' (placement), but doesn't explicitly contrast them. Purpose is clear but sibling differentiation is implicit.
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 explicit guidance on when to use this tool versus alternatives. The description implies it's for setting default agent properties, but doesn't mention prerequisites (e.g., whether agents must exist), timing relative to other operations, or when to use sibling tools like 'bulc_modify_evac_stair' for stair-specific settings. Usage context is assumed rather than stated.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, covering the mutation aspect. The description adds context by specifying what gets set (ambient conditions), but doesn't detail side effects, permissions, or rate limits. No contradiction with annotations exists.
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 no wasted words. It front-loads the core action and key parameters, 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?
For a destructive tool with no output schema, the description is adequate but lacks details on behavioral impact or return values. It covers the basic purpose but doesn't fully compensate for the absence of output information or deeper usage context.
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 100%, so parameters are well-documented in the schema. The description lists temperature, pressure, and species, which partially maps to parameters (species implies mass fractions), but adds minimal value beyond the schema. Baseline 3 is appropriate.
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 ('Set') and resource ('FDS ambient conditions') with specific attributes (temperature, pressure, species). It distinguishes from siblings like 'bulc_set_fds_fire_source' or 'bulc_set_evac_time' by focusing on ambient conditions, though it doesn't explicitly contrast them.
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 is provided. The description doesn't mention prerequisites, timing in workflow, or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't explicitly address. However, it adds useful context beyond annotations: it explains that the tool sets thresholds that 'affect agent behavior,' implying a configuration change that could alter simulation outcomes. It doesn't detail the destructive nature (e.g., overwriting previous settings) or other behavioral traits like side effects or error handling, but with annotations covering the safety profile, this provides moderate additional value.
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: it states the core purpose in the first clause and adds key behavioral context in the second sentence. Every word earns its place, with no redundancy or fluff, making it efficient for an agent to parse.
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 complexity (7 parameters, destructive hint, no output schema), the description is minimally adequate. It covers the basic purpose and effect on agent behavior but lacks details on usage context, prerequisites, or expected outcomes. With annotations providing safety hints and schema covering parameters, it's complete enough for basic understanding but leaves gaps for informed tool invocation.
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 input schema has 100% description coverage, so parameters like 'enabled' and 'visibilityThreshold' are well-documented in the schema. The description adds no specific parameter information beyond implying that thresholds influence agent avoidance. This meets the baseline of 3, as the schema carries the full burden of parameter 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: 'Configure fire-evacuation coupling for FDS+EVAC integration.' It specifies the action ('Configure') and the resource ('fire-evacuation coupling'), and mentions the integration context. However, it doesn't explicitly differentiate from sibling tools like 'bulc_set_evac_model' or 'bulc_set_fds_fire_source', which might also affect agent behavior in related ways.
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 mentions that it 'affects agent behavior,' but doesn't specify prerequisites (e.g., after running FDS simulations), exclusions (e.g., not for standalone EVAC), or direct alternatives among the many sibling tools. This leaves the agent with minimal contextual cues for tool selection.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context by specifying what data is returned (progress, evacuated count, completion time), which goes beyond the annotations. However, it doesn't mention potential limitations like real-time updates, caching behavior, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key return data. It's front-loaded with the main action and includes specific details without unnecessary elaboration, making it easy for an agent 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?
For a read-only tool with no parameters and no output schema, the description adequately covers the basic purpose and return data. However, it lacks details on output format (e.g., structured data vs. raw text), potential errors, or how it integrates with sibling tools like 'bulc_run_evac' or 'bulc_stop_evac', leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output semantics. This meets the baseline of 4 for tools with no parameters.
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 ('Get') and resource ('evacuation simulation status'), including key data points like progress, evacuated count, and estimated completion time. However, it doesn't explicitly differentiate from sibling tools like 'bulc_get_evac_result' or 'bulc_get_evac_summary', which might provide overlapping or related information.
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. Given sibling tools like 'bulc_get_evac_result' and 'bulc_get_evac_summary', there's no indication of when this status check is appropriate versus retrieving results or summaries, leaving the agent to guess based on tool names alone.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context by specifying what types of settings are retrieved, which helps anticipate the return structure. However, it doesn't disclose behavioral details like whether it returns defaults or current values, error conditions, or if it requires a simulation to be loaded. With annotations covering safety, this is adequate but not rich.
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 front-loads the purpose ('Get current FDS simulation settings') and lists key components. There is no wasted verbiage, and every word contributes to understanding the tool's scope.
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 no parameters, annotations cover safety, and no output schema exists, the description is minimally complete. It specifies what settings are included, which helps infer the return value. However, for a read operation with potential complexity in returned data, it could benefit from more detail on output format or structure to fully compensate for the lack of output schema.
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 schema description coverage is 100% (empty schema). The description doesn't need to add parameter details, so it meets the baseline of 4 for zero-parameter tools. It appropriately focuses on what the tool retrieves rather than inputs.
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 'Get' and the resource 'FDS simulation settings', with specific examples of what settings are included (time, ambient conditions, output settings, numerical parameters). It distinguishes from siblings like 'bulc_get_fds_data' or 'bulc_get_fds_status' by focusing on configuration rather than runtime data or status. However, it doesn't explicitly contrast with these siblings, so it's not a perfect 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., after setting up a simulation), exclusions (e.g., not for evac settings), or direct alternatives among siblings like 'bulc_get_evac_settings'. Usage is implied from the name but not explicitly stated.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it lists 'configured' evacuation stairs, which implies it returns pre-set data rather than real-time status, but doesn't disclose behavioral traits like pagination, format, or error handling. With annotations covering safety, it adds minimal context beyond them.
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?
Single sentence, front-loaded with the core action ('List all configured evacuation stairs'), and efficiently specifies the scope ('for multi-level buildings'). No wasted words or redundancy, making it highly concise 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 0 parameters, annotations indicating a safe read, and no output schema, the description is adequate but minimal. It states what the tool does but lacks details on return format, error cases, or integration with other tools like 'bulc_setup_evac_stair'. For a simple list tool, it's complete enough but could be more informative.
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?
There are 0 parameters, and schema description coverage is 100%, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, as there are none to explain. Baseline for 0 parameters is 4, since no compensation is needed.
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 ('List') and resource ('all configured evacuation stairs'), specifying it's for multi-level buildings. It distinguishes from siblings like 'bulc_list_evac_exits' or 'bulc_list_rooms' by focusing on stairs, but doesn't explicitly contrast with them. Purpose is specific but lacks explicit sibling differentiation.
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 'bulc_get_evac_result' or 'bulc_list_evac_agents'. The description implies usage for listing evacuation stairs, but doesn't specify context, prerequisites, or exclusions. It's a basic statement without operational context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying the data returned (names, elevations, floor heights), but doesn't cover behavioral aspects like response format, pagination, or error conditions beyond what annotations provide.
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 front-loads the purpose and key details without any wasted words. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no parameters and no output schema, the description is adequate but minimal. It specifies what data is returned, but lacks context on format, ordering, or completeness, which could be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
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 ('Get') and resource ('all floor levels') with specific attributes (names, elevations, floor heights). It distinguishes from many siblings (e.g., bulc_list_rooms, bulc_list_walls) by specifying floor levels, though it doesn't explicitly differentiate from all list tools.
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 doesn't mention prerequisites, context, or compare with other list tools like bulc_list_rooms or bulc_list_walls, leaving the agent to infer usage.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying mutation ('undo') without contradiction. The description adds value by specifying that it returns information about what was undone, which isn't covered by annotations. However, it lacks details on side effects, error conditions, or rate limits, keeping the score moderate.
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 are front-loaded and waste no words. The first sentence states the action, and the second adds crucial return information, making it highly efficient and well-structured for quick 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 the tool's complexity (destructive operation with no parameters) and lack of output schema, the description is minimally adequate. It covers the basic action and return info but misses details like error handling, what constitutes 'last operation,' or dependencies on other tools. With annotations providing safety cues, it's complete enough but not robust.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, so it meets the baseline. It efficiently avoids redundancy, though it doesn't explicitly state 'no parameters required,' which is a minor gap.
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 ('undo') and the resource ('last operation'), making the purpose specific and understandable. It distinguishes from siblings like 'bulc_redo' by focusing on reversal rather than repetition. However, it doesn't specify what types of operations can be undone (e.g., creation, deletion, modification), 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 or prerequisites. It doesn't mention if there are limitations (e.g., only one undo level, specific operation types), nor does it reference sibling tools like 'bulc_redo' for context. This leaves 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior, which the description aligns with by implying a validation/checking function. However, the description adds minimal behavioral context beyond annotations—it doesn't detail output format, error severity levels, or performance implications, relying on annotations for safety profile.
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, consisting of two efficient sentences that directly state the purpose and scope. Every word contributes to understanding without redundancy or fluff, making it easy to parse.
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 complexity (validation of multiple setup aspects), annotations cover safety, but there's no output schema, and the description lacks details on return values or error handling. It's minimally adequate but leaves gaps in understanding what results to expect from the validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage), so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it implicitly suggests the tool operates on the current evacuation setup without inputs, aligning with the 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 tool's purpose: 'Validate evacuation setup for errors and warnings' with specific checks on 'agents, exits, walkable areas, and stair configurations.' It uses a specific verb ('validate') and identifies the resource ('evacuation setup'), though it doesn't explicitly differentiate from sibling tools like 'bulc_validate_fds' beyond the domain 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?
No guidance is provided on when to use this tool versus alternatives. The description lists what it checks but doesn't specify prerequisites (e.g., after setup), exclusions, or comparisons to other validation or diagnostic tools 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true, which already signal that this is a mutation tool with potential destructive effects. The description adds value by clarifying that the mesh 'defines the computational domain for fire simulation', implying it's foundational for simulations. However, it doesn't detail what 'destructive' entails (e.g., overwriting existing meshes, affecting simulations) or any side effects like performance impacts or validation needs.
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, well-structured sentence that front-loads the core action ('Create a new FDS computational mesh') and efficiently adds context ('with specified dimensions and cell count' and 'defines the computational domain for fire simulation'). Every word contributes meaning without redundancy or fluff, making it highly concise and clear.
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 complexity (11 parameters, destructive mutation) and lack of an output schema, the description is minimally adequate. It explains what the tool does and the mesh's purpose, but doesn't cover critical aspects like what the tool returns (e.g., a confirmation, mesh ID, error details), how it integrates with other tools (e.g., 'bulc_run_fds'), or the implications of the destructive hint. With annotations providing safety cues, it's complete enough for basic use but lacks depth for informed agent decisions.
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 100% schema description coverage, the input schema fully documents all 11 parameters, including their types, defaults, and purposes. The description adds no parameter-specific details beyond what's in the schema, such as explaining interactions between 'cellSize' and 'iCells/jCells/kCells'. Thus, it meets the baseline of 3 for high schema coverage without extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new FDS computational mesh') and the resource ('mesh'), distinguishing it from siblings like 'bulc_auto_mesh' (which likely automates mesh creation) or 'bulc_modify_mesh' (which modifies existing meshes). It also explains the mesh's purpose ('defines the computational domain for fire simulation'), adding context beyond just the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'bulc_auto_mesh' or 'bulc_modify_mesh'. It mentions the mesh's role in fire simulation, but does not specify prerequisites, dependencies, or scenarios where manual mesh creation is preferred over automated methods. This leaves the agent without clear usage context.
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?
Annotations indicate read-only and non-destructive behavior, which the description doesn't contradict. The description adds value by specifying the types of data retrievable (e.g., temperature, visibility) and the simulation domain context, but it doesn't disclose additional behavioral traits like rate limits, authentication needs, or output format details, which are relevant given the lack of an output schema.
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 well-structured, consisting of two sentences that efficiently convey the core purpose and utility without any redundant information. It is front-loaded with the main action and avoids unnecessary elaboration.
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 complexity (point-specific data extraction in a simulation), annotations cover safety, and the schema fully describes inputs, but the lack of an output schema means the description should ideally hint at return values (e.g., time-series format). It partially compensates by listing data types, but more context on output behavior would enhance completeness for effective agent use.
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 100% schema description coverage, the input schema fully documents all parameters. The description adds minimal semantics by listing example variables ('temperature, visibility, or species concentration') that align with the 'variable' enum, but it doesn't provide extra context beyond what the schema already specifies, such as coordinate system details or data source implications.
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 ('Extract') and resource ('time-series data at a specific point'), and identifies typical use cases ('temperature, visibility, or species concentration'). However, it doesn't explicitly differentiate from sibling tools like 'bulc_get_fds_data' or 'bulc_get_spatial_context', which might also retrieve data but with different scopes or formats.
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 context by stating it's 'useful for getting' specific variables at a location, which suggests when to use it. However, it lacks explicit guidance on when not to use it or alternatives among siblings, such as whether to prefer this over bulk data retrieval tools for point-specific queries.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by using 'Modify' and 'Update'. The description adds value by specifying which properties can be modified (capacity, speed, position), which isn't covered by annotations. However, it doesn't disclose potential side effects (e.g., impact on evacuation simulations) or error conditions, leaving some 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 a single, efficient sentence that front-loads the core action ('Modify an existing evacuation stair configuration') and lists key updatable properties. There is no wasted text, and it's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given destructiveHint=true, no output schema, and 8 parameters, the description is minimally adequate. It covers the purpose and key properties but lacks details on behavioral implications (e.g., how modifications affect simulations), error handling, or return values. With annotations providing safety context, it's complete enough for basic use but could be more informative.
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 100%, so the schema fully documents all 8 parameters. The description mentions 'capacity, speed, or position properties', which loosely maps to parameters like capacity, travelSpeed, and entry/exit coordinates, but adds no syntax, units, or constraints beyond the schema. This meets the baseline for high schema coverage.
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') and resource ('existing evacuation stair configuration'), and specifies the properties that can be updated ('capacity, speed, or position'). It distinguishes from siblings like 'bulc_setup_evac_stair' (creation) and 'bulc_clear_evac_stair' (deletion), though it doesn't explicitly name them. However, it could be more specific about what 'position properties' entails.
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., an existing stair must be identified by furnitureId), exclusions, or comparisons to siblings like 'bulc_modify_furniture' or 'bulc_setup_evac_stair'. Usage is implied by the verb 'Modify' but lacks explicit context.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a write operation ('Save'). The description adds context by specifying the output format ('.evac file') and that it saves 'current' results, which isn't covered by annotations. However, it doesn't detail side effects like overwriting files or requiring prior simulation results.
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 with the core action and outcome, 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?
For a destructive write tool with no output schema, the description is minimally adequate. It specifies what is saved and the file format, but lacks details on error conditions, dependencies (e.g., requires existing evacuation results), or output behavior. Given the annotations cover safety aspects, it meets a basic threshold but could be more informative.
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 100%, with both parameters well-documented in the schema (outputPath and filename). The description adds no additional parameter semantics beyond implying the tool saves results, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 ('Save') and target ('current evacuation results to a .evac file'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'bulc_save' or 'bulc_export_fds', which might have overlapping save/export 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. With siblings like 'bulc_save' (general save), 'bulc_export_fds' (FDS export), and 'bulc_load_evac_result' (load counterpart), there's no indication of context, prerequisites, or exclusions for this specific save operation.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a configuration change ('Set'). However, it adds minimal behavioral context beyond annotations—it does not specify if this affects ongoing simulations, requires specific permissions, or has side effects like resetting other parameters. The description does not contradict annotations but offers limited extra insight.
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 front-loads the core action and lists the supported models. Every word contributes directly to understanding the tool's function, with no redundant or vague phrasing. It is appropriately sized for a configuration-setting tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive configuration tool with no output schema, the description is minimally adequate. It covers the purpose and model options but lacks context on usage, effects, or integration with other tools (e.g., 'bulc_run_evac'). Given the annotations provide safety hints, the description meets basic needs but leaves gaps in operational guidance.
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 100%, with each parameter well-documented in the schema (e.g., defaults, units, model associations). The description only mentions the model types, which the schema already covers via the 'model' enum. It adds no meaningful semantics beyond the schema, so the baseline score of 3 is appropriate given the comprehensive 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 specific action ('Set') and resource ('evacuation simulation model type and parameters'), distinguishing it from siblings like 'bulc_get_evac_settings' (which retrieves) or 'bulc_run_evac' (which executes). It explicitly lists the three supported model types, making the purpose unambiguous and distinct.
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 (e.g., whether an evacuation simulation must be configured first), exclusions, or related tools like 'bulc_get_evac_settings' for checking current settings. Usage is implied only through the action 'Set', with no explicit context.
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?
Annotations already indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true). The description adds useful context about what gets modified ('evacuation simulation time parameters'), but doesn't provide additional behavioral details like whether changes are reversible, if there are validation constraints, or what happens to ongoing simulations. No contradiction with annotations exists.
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 perfectly concise with two sentences that each earn their place. The first sentence establishes the core purpose, and the second clarifies the scope of control. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema, the description adequately covers the basic purpose but lacks important contextual information. It doesn't explain what happens after setting these parameters, whether validation occurs, or how this interacts with other evacuation tools. Given the complexity implied by the sibling tools list, more completeness would be helpful.
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 100% schema description coverage, the input schema already fully documents both parameters with clear descriptions and defaults. The description adds marginal value by confirming these parameters control 'total simulation duration and time step resolution,' but doesn't provide additional semantic context beyond what's 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 the specific action ('Set'), the target resource ('evacuation simulation time parameters'), and the scope of control ('total simulation duration and time step resolution'). It distinguishes itself from sibling tools like 'bulc_set_simulation_time' by focusing specifically on evacuation simulation timing rather than general simulation time settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'bulc_set_simulation_time' or 'bulc_set_evac_model', nor does it mention prerequisites such as needing an existing evacuation simulation setup. It simply states what the tool does without contextual usage information.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds context about what the tool determines (exit choice behavior), but doesn't elaborate on side effects, permissions needed, or system state changes beyond what annotations already cover. It provides some behavioral insight but lacks depth for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, focused sentences with zero wasted words. The first sentence states the core action, and the second explains the behavioral impact. It's front-loaded and efficiently communicates the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description adequately covers the basic purpose but lacks details about return values, error conditions, or system state changes. Given the complexity of evacuation simulation and the destructive nature, more context about consequences would be helpful, though annotations provide some safety information.
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 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the tool's purpose generally but doesn't clarify parameter interactions or usage examples, meeting the baseline for high schema coverage.
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 specific action ('Set the exit assignment strategy') and resource ('for evacuation agents'), with additional detail on what it determines ('how agents choose which exit to use'). It distinguishes from siblings like 'bulc_set_agent_properties' or 'bulc_set_evac_model' by focusing specifically on exit assignment logic.
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. The description doesn't mention prerequisites (e.g., whether evacuation agents must exist first), nor does it differentiate from sibling tools like 'bulc_set_agent_properties' that might affect agent behavior. Usage context is implied but not explicitly stated.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying configuration changes. The description adds valuable context beyond annotations: it specifies that the fire uses the furniture's surface area for calculations and supports HRRPUA mode with ramping, which are behavioral details not covered by annotations. However, it lacks information on permissions, side effects, or error handling.
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 front-loaded with the core purpose in the first sentence, followed by supporting details in a second sentence. Both sentences are essential, with no redundant information, making it highly 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 destructive nature (annotations), 6 parameters, and no output schema, the description is adequate but incomplete. It covers the tool's function and key behavioral aspects but lacks details on outcomes, error conditions, or integration with other tools, which could hinder an agent's understanding in a complex simulation context.
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 100% schema description coverage, the input schema fully documents all 6 parameters. The description adds minimal semantic value, only hinting at the purpose of 'hrrpua' and 'ramp' in the context of fire configuration. It doesn't explain parameter interactions or provide examples beyond what's in the schema, meeting the baseline for high coverage.
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 ('Configure a furniture item as an FDS fire source') and specifies the mode ('HRRPUA mode with time-based ramping'), which distinguishes it from other fire-related tools like 'bulc_set_fds_sprinkler' or 'bulc_set_fds_thermocouple'. However, it doesn't explicitly differentiate from all siblings, such as 'bulc_set_fire_coupling', which might also involve fire configuration.
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 other fire-setting tools in the sibling list. It mentions the mode (HRRPUA) but doesn't specify prerequisites, exclusions, or comparative contexts, leaving the agent without clear usage direction.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds valuable context beyond annotations by specifying that it configures for 'thermal response' and 'suppression simulation', giving insight into the tool's functional behavior. However, it does not detail side effects like data overwrites or performance impacts.
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 front-loads the core action and key parameters without redundancy. Every word contributes to understanding the tool's function, making it appropriately sized 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 destructiveHint=true annotation and lack of output schema, the description adequately covers the basic configuration purpose but could be more complete. It does not explain what happens to existing sprinkler configurations, error conditions, or return values, which are important for a destructive operation with 8 parameters.
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 100% schema description coverage, the input schema fully documents all 8 parameters. The description adds minimal semantics by mentioning 'RTI and activation temperature for thermal response' and 'water spray parameters for suppression simulation', which loosely maps to some parameters but does not provide additional syntax or constraints beyond the 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 verb ('configure') and resource ('a furniture item as an FDS sprinkler'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'bulc_set_fds_detector' or 'bulc_set_fds_fire_source', which also configure FDS components, so it misses full sibling distinction.
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 other FDS configuration tools in the sibling list. It lacks context on prerequisites, dependencies, or scenarios where this tool is appropriate, leaving the agent without usage direction.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a write operation that modifies data. The description adds value by specifying it 'controls simulation duration and time step settings', which clarifies the scope of modification. It doesn't mention side effects like validation or dependencies, but provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero wasted words. It's front-loaded with the core purpose and efficiently explains the scope. Every sentence earns its place by adding necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description adequately covers what the tool does but lacks information about effects, dependencies, or return values. It's minimally complete given the annotations provide safety context, but doesn't fully address the mutation's impact or integration with other simulation steps.
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 100%, with clear parameter documentation. The description adds minimal value beyond the schema, only implying that parameters relate to 'duration and time step settings'. No additional syntax, constraints, or interaction details are provided, meeting the baseline for high schema coverage.
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 ('Set') and resource ('FDS simulation time parameters'), specifying it controls 'simulation duration and time step settings'. This distinguishes it from siblings like 'bulc_set_evac_time' or 'bulc_set_fds_fire_source', though it doesn't explicitly mention those alternatives. The purpose is specific but could be more differentiated.
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, timing within a workflow, or exclusions. With many sibling tools for simulation settings, this lack of context leaves the agent guessing about appropriate usage scenarios.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about returning catalog IDs needed for placement, which isn't covered by annotations. However, it doesn't disclose behavioral traits like pagination, rate limits, or error conditions beyond what annotations provide.
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 sentences that both earn their place: the first states the core purpose, the second provides filtering guidance and downstream usage context. No wasted words, perfectly front-loaded with essential 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?
For a read-only list operation with full parameter documentation and clear annotations, the description provides adequate context. The mention of catalog IDs for placement adds valuable downstream usage information. The main gap is the lack of output schema, but the description compensates somewhat by indicating what the return values are used for.
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 100% schema description coverage, the input schema already fully documents all three parameters (category, search, limit) with clear descriptions and defaults. The description mentions the category filter but adds no additional semantic information beyond what's in the schema, meeting the baseline for high schema coverage.
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 ('Get a list') and resource ('available furniture items from the catalog'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this from sibling tools like 'bulc_list_furniture' or 'bulc_place_furniture' beyond mentioning the latter in the return value context.
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 mentioning the category filter and referencing 'bulc_place_furniture' as a downstream tool, but it doesn't explicitly state when to use this versus alternatives like 'bulc_list_furniture' or other catalog-related tools. No explicit when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive, but the description adds context about opening a viewer window and loading results, which suggests a UI interaction rather than a data mutation. It doesn't disclose behavioral traits like whether it blocks other operations, requires specific permissions, or has side effects beyond what annotations cover.
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 front-loads the core action ('Open the FDS result viewer window') and adds necessary detail about loading sources. There is no wasted verbiage, making it appropriately sized for its purpose.
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 moderate complexity (opening a viewer with two optional parameters), annotations cover safety aspects, and schema fully describes inputs. The description adequately explains the tool's purpose and loading behavior. However, without an output schema, it doesn't clarify what happens after opening (e.g., success indication or error handling), leaving a minor gap.
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 input schema has 100% description coverage, fully documenting both parameters. The description adds no additional parameter semantics beyond implying 'smvPath' defaults to auto-detection, which is already stated in the schema. This meets the baseline for high schema coverage.
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 ('Open the FDS result viewer window') and resource ('simulation results'), specifying it loads from an SMV file or last simulation. It distinguishes from siblings like 'bulc_open_evac_viewer' by focusing on FDS results rather than evacuation results, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning loading from 'specified SMV file or last simulation', suggesting it's for viewing FDS simulation results. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'bulc_get_fds_data' or 'bulc_preview_fds', nor does it mention prerequisites or exclusions.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a write operation that modifies data. The description adds valuable context beyond annotations: it explains the functional difference between supply and exhaust vents ('Supply vents blow air in, exhaust vents extract air out'), which helps the agent understand the behavioral impact of surface assignments. However, it doesn't mention potential side effects like overwriting existing configurations or rate limits.
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 core purpose and efficiently explains key concepts (supply vs. exhaust) in two sentences. No redundant information is present, though it could be slightly more structured by explicitly mentioning parameter roles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive configuration tool with no output schema, the description is adequate but has gaps. It covers the purpose and basic behavior but lacks details on error conditions, what happens on success (e.g., confirmation message), or how changes propagate in the system. Given the complexity (6 parameters, nested objects), more context would be beneficial.
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 100%, so all parameters are documented in the schema. The description adds minimal semantic value beyond the schema—it mentions 'surface properties' and 'specific faces' but doesn't elaborate on parameter interactions or usage examples. Baseline 3 is appropriate as the schema carries the documentation burden.
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 specific action ('Configure a furniture item as an FDS HVAC'), identifies the resource ('furniture item'), and distinguishes from siblings by specifying it's for HVAC vents (supply/exhaust) rather than other FDS components like detectors, fire sources, or sprinklers listed in 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While it distinguishes itself from other FDS tools by focusing on HVAC, it doesn't mention prerequisites (e.g., furniture must exist), exclusions, or compare with similar configuration tools like bulc_set_fds_detector or bulc_set_fds_sprinkler.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a mutation that may cause irreversible changes. The description adds context by specifying it stops 'a running evacuation simulation,' which aligns with the destructive nature. However, it doesn't detail side effects like data loss or state changes beyond stopping.
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 with no wasted words. It's front-loaded with the core action and target, 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?
For a destructive tool with no output schema, the description adequately states what it does but lacks details on outcomes (e.g., what 'stop' entails, error conditions, or return values). Annotations cover safety, but more behavioral context would help, given the complexity implied by sibling tools.
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?
With 0 parameters and 100% schema description coverage, the input schema fully documents the lack of inputs. The description doesn't need to add parameter details, but it could mention if any implicit context (e.g., current simulation) is required. Baseline is 4 for zero parameters.
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 ('Stop') and the target ('a running evacuation simulation'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'bulc_stop_fds' (which stops a different simulation type), leaving some ambiguity about scope.
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, prerequisites (e.g., whether an evacuation simulation must be running), or consequences of stopping. It mentions 'running' but doesn't clarify what happens if invoked when no simulation is active.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds context about what gets validated (mesh consistency, fire source setup, etc.), which is useful beyond annotations. However, it doesn't disclose behavioral traits like output format, error handling, or performance characteristics. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one stating the core purpose and another listing specific checks. Every word adds value without redundancy, and it's front-loaded with the main action. There's no wasted verbiage or unnecessary elaboration.
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 complexity (validation of multiple FDS aspects), annotations cover safety (read-only, non-destructive), but there's no output schema. The description adequately explains what is validated but doesn't detail the return format (e.g., error list, summary report) or how results are presented. For a validation tool, more output context would be helpful, though the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate here since none exist. It effectively compensates by focusing on the tool's purpose rather than parameter details, aligning with the zero-parameter baseline.
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: 'Validate FDS configuration for errors and warnings' with specific checks listed (mesh consistency, fire source setup, boundary conditions). It distinguishes from siblings like 'bulc_validate_evac' by focusing on FDS rather than evacuation validation. However, it doesn't explicitly contrast with other validation or diagnostic tools beyond naming differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Validate FDS configuration' and the listed checks, suggesting it should be used before running simulations or after configuration changes. However, it doesn't explicitly state when to use it versus alternatives like 'bulc_preview_fds' or 'bulc_get_fds_status', nor does it provide prerequisites or exclusions. The guidance is implied rather than explicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context by specifying the type of data returned (summary statistics), which is useful beyond annotations. However, it doesn't mention potential limitations like requiring a loaded result or error conditions, so it adds some but not comprehensive behavioral insight.
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 front-loads the core purpose ('Get evacuation result summary') and lists key output details. There is no wasted verbiage, making it easy to parse and understand quickly, which is ideal for a tool with no parameters.
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 0 parameters, annotations covering safety, and no output schema, the description is reasonably complete. It explains what the tool does and what data to expect. However, it could be more comprehensive by clarifying dependencies (e.g., requires a simulation result) or output 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing instead on the tool's output. This aligns well with the schema, earning a high score as it doesn't introduce unnecessary details.
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 specific verbs ('Get evacuation result summary') and resources ('evacuation result'), and lists the data included ('total time, per-agent exit times, and statistics'). It distinguishes itself from siblings like 'bulc_get_evac_result' by focusing on a summary rather than full results, though the distinction could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after an evacuation simulation (e.g., 'result summary'), suggesting it should be used when summary data is needed. However, it lacks explicit guidance on when to use this tool versus alternatives like 'bulc_get_evac_result' or prerequisites such as needing a completed simulation, leaving room for ambiguity.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating this is a destructive write operation. The description adds useful context about partial updates ('Only specified properties will be changed'), which isn't captured in annotations. However, it doesn't disclose other behavioral traits like permission requirements, error conditions, or what happens to unspecified properties.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides crucial behavioral context about partial updates and directs to the ID source tool. No wasted words, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive modification tool with no output schema, the description provides adequate but minimal context. It covers the basic purpose and partial update behavior, but lacks information about return values, error handling, or system state changes. Given the destructive annotation and 7 parameters, more completeness would be beneficial.
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 100% schema description coverage, the schema already documents all 7 parameters thoroughly. The description adds minimal value by mentioning wall IDs come from 'bulc_list_walls', which is already in the schema's id description. No additional parameter semantics are provided beyond what's in the structured 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 verb ('Modify') and resource ('properties of an existing wall'), making the purpose explicit. It distinguishes from sibling 'bulc_create_wall' by specifying 'existing wall', but doesn't differentiate from other modify tools like 'bulc_modify_room' or 'bulc_modify_furniture' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Modify properties of an existing wall') and explicitly directs users to get wall IDs from 'bulc_list_walls'. However, it doesn't specify when NOT to use this tool or mention alternatives like 'bulc_delete_wall' followed by recreation.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, confirming this is a write operation that modifies state. The description adds valuable context beyond annotations: it specifies that placement can be 'random distribution' or 'at exact coordinates,' and implies that either 'count' or 'positions' must be provided. This clarifies behavioral aspects not covered by annotations, though it doesn't detail side effects like overwriting existing agents or interaction with other tools.
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 and front-loaded, consisting of a single sentence that directly states the tool's purpose and key functionality. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the core action and options without unnecessary detail.
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 complexity (destructive operation with 8 parameters) and lack of output schema, the description is minimally adequate. It covers the basic purpose and placement modes but doesn't address important contextual details like prerequisites (e.g., must agents be defined first?), effects on existing agents, or relationship to other evacuation tools. With annotations providing safety context, the description meets minimum viability but leaves gaps in operational context.
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 input schema has 100% description coverage, providing clear documentation for all 8 parameters. The description adds minimal semantic value beyond the schema, only hinting at the 'count' vs. 'positions' alternative usage. Since the schema already fully describes parameters, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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: 'Place evacuation agents in rooms or at specific positions.' It specifies the verb ('place') and resource ('evacuation agents'), and distinguishes placement methods ('by count' vs. 'at exact coordinates'). However, it doesn't explicitly differentiate from sibling tools like 'bulc_set_agent_properties' or 'bulc_list_evac_agents', 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning two placement modes ('by count' or 'at exact coordinates'), but it doesn't provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for initial setup versus runtime adjustments, or how it relates to tools like 'bulc_set_agent_properties'. The guidance is present but limited to operational modes rather than broader context.
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?
Annotations indicate read-only and non-destructive operations, which the description aligns with by describing an analysis that evaluates criteria without implying modification. The description adds valuable context about the specific safety criteria evaluated (temperature, visibility, CO, CO2, O2), which goes beyond the annotations and helps the agent understand 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, dense sentence that efficiently conveys the tool's purpose and key details (exit location, safety criteria with specific thresholds). Every part earns its place with no wasted words, making it easy to parse and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with no output schema, the description adequately covers the action and criteria but lacks details on output format (e.g., time values, pass/fail status) or integration with other tools. Given the complexity of safety analysis, more context on results or dependencies would enhance 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?
With 100% schema description coverage, the input schema fully documents all parameters (exit coordinates and optional criteria). The description mentions 'specified exit location' and 'safety criteria' but doesn't add semantic details beyond what the schema provides, such as coordinate system context or criteria interpretation, meeting the baseline for high schema coverage.
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 specific action ('Run ASET analysis') and resource ('at a specified exit location'), with detailed safety criteria. It distinguishes itself from siblings like 'bulc_run_evac' or 'bulc_run_fds' by focusing on ASET analysis rather than evacuation or fire dynamics simulations.
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 simulation data), exclusions, or how it relates to sibling tools like 'bulc_get_evac_result' or 'bulc_get_fds_data', leaving the agent without context for tool selection.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a configuration change ('Set'). The description adds value by specifying that parameters include 'statistical distributions', which provides context beyond the annotations about the tool's behavioral complexity, though it doesn't detail side effects like overwriting existing settings.
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 front-loads the core purpose without any redundant information. Every word earns its place by specifying the action, target, and key parameters, making it highly concise 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's complexity (8 parameters, destructive operation) and lack of output schema, the description is adequate but has gaps. It covers the purpose and hints at parameter types, but doesn't explain return values, error conditions, or dependencies on other tools like 'bulc_place_evac_agents', leaving room for improvement in 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 description coverage is 100%, so the schema fully documents all 8 parameters. The description adds minimal semantics by mentioning 'detection time and reaction time with statistical distributions', which loosely maps to some parameters but doesn't provide additional syntax or format details beyond what the schema already specifies, meeting the baseline for high coverage.
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 specific action ('Set pre-movement time parameters') and the target resource ('evacuation agents'), distinguishing it from siblings like 'bulc_set_agent_properties' or 'bulc_set_evac_time'. It also specifies what's included ('detection time and reaction time with statistical distributions'), 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'bulc_set_agent_properties' or 'bulc_set_evac_time', nor does it mention prerequisites such as needing evacuation agents to be placed first. It lacks explicit when/when-not instructions or named alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying configuration changes. The description adds valuable context beyond annotations by specifying what gets configured (entry/exit positions, capacity, travel speed) and the resource type (furniture item as stair connection), though it doesn't detail side effects like overwriting existing stair settings or validation 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?
The description is a single, efficient sentence that front-loads the core action ('Configure a furniture item as an evacuation stair connection') and follows with key configuration aspects. Every word contributes to understanding the tool's purpose without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive configuration tool with 10 parameters and no output schema, the description is adequate but incomplete. It covers the basic purpose and configuration scope, but lacks details on behavioral outcomes (e.g., what happens if the furnitureId is invalid), error conditions, or return values, which are important given the tool's complexity and destructive nature.
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 100% schema description coverage, the input schema fully documents all 10 parameters. The description adds minimal semantics by mentioning 'entry/exit positions, capacity, and travel speed', which loosely maps to parameters like entryX/Y, exitX/Y, capacity, and travelSpeed, but doesn't provide additional meaning or usage context beyond what the schema already specifies.
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 specific action ('Configure a furniture item as an evacuation stair connection') and resource ('between floors'), distinguishing it from siblings like 'bulc_clear_evac_stair' (which removes stairs) and 'bulc_modify_evac_stair' (which modifies existing stairs). It explicitly defines the configuration scope with 'entry/exit positions, capacity, and travel speed'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'bulc_modify_evac_stair' or 'bulc_clear_evac_stair', nor does it mention prerequisites such as needing an existing furniture item or valid floor indices. It lacks context about whether this is for initial setup or replacement.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by using 'Clear' and 'Removes'. The description adds valuable context beyond annotations by specifying exactly what types of FDS settings get removed (fire source, detector, sprinkler, HVAC, thermocouple), which helps the agent understand the scope of the destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences: the first states the core purpose, and the second provides specific examples of what gets cleared. Every word earns its place, and the structure is front-loaded with the main action.
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?
For a destructive operation with good annotations and a simple single parameter, the description provides adequate context. It specifies what gets cleared, aligns with annotations, and distinguishes from read/set operations. The main gap is lack of output information (no output schema), but the description compensates reasonably given the tool's straightforward nature.
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 100% with the single parameter 'furnitureId' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate as the schema carries the full burden.
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 ('Clear FDS configuration') and target ('from a furniture item'), with specific examples of what gets removed (fire source, detector, sprinkler, HVAC, thermocouple settings). It distinguishes from siblings like 'bulc_get_fds_data' (read) and 'bulc_set_fds_*' tools (configure), but doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when FDS configuration needs to be removed from furniture, suggesting it's for resetting or clearing settings. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'bulc_delete_furniture' or 'bulc_modify_furniture', nor does it mention prerequisites or exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the return format (IDs, names, positions, dimensions) and the purpose of IDs for subsequent operations, which goes beyond annotations. However, it doesn't disclose behavioral traits like pagination, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a usage note. Every word adds value without redundancy, making it efficiently structured 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's simplicity (one optional parameter, read-only, no output schema), the description is largely complete. It covers the purpose, return data, and usage context. A 5 is reserved for tools with more complexity that require additional disclosures (e.g., side effects), which isn't needed here.
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 100%, with the parameter 'level' fully documented in the schema as an optional filter by floor level index. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('all rooms') with specific attributes (IDs, names, positions, dimensions), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'bulc_list_levels' or 'bulc_list_walls' beyond the resource type, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by stating that returned IDs are used for modify/delete operations, which helps the agent understand when to call this tool (e.g., before performing updates). It doesn't explicitly mention when not to use it or name alternatives among siblings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate 'readOnlyHint: false' and 'destructiveHint: true', which already convey that this is a mutable, potentially destructive operation. The description adds value by specifying 'Only specified properties will be changed', clarifying partial updates, but doesn't disclose additional behavioral traits like error handling, permissions, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Modify properties of an existing furniture item'), followed by essential guidance. Every sentence earns its place by providing key information without redundancy, making it highly efficient and well-structured.
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 (10 parameters, destructive mutation) and lack of output schema, the description is reasonably complete. It covers the purpose, partial update behavior, and ID sourcing, but could benefit from mentioning response format or error cases. Annotations provide safety context, so the description doesn't need to repeat that.
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 100%, with each parameter clearly documented in the input schema (e.g., 'id' as 'Furniture ID to modify', 'x' as 'New X coordinate (cm)'). The description doesn't add extra meaning beyond this, as it only references the 'id' parameter indirectly. Baseline 3 is appropriate since the schema handles parameter documentation effectively.
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 ('Modify') and resource ('properties of an existing furniture item'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'bulc_delete_furniture' or 'bulc_place_furniture', which would require mentioning it's for updates rather than creation or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Only specified properties will be changed' and directing users to 'Get furniture IDs from bulc_list_furniture', which helps in understanding when to use this tool. It doesn't explicitly mention alternatives like 'bulc_place_furniture' for new items, but the guidance is sufficient for basic usage.
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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating this is a write operation with potential destructive effects. The description adds valuable context about the asynchronous execution pattern (runs in background, returns immediately) and the monitoring workflow, which isn't captured in annotations. However, it doesn't elaborate on what 'destructive' means in this context or mention rate limits, auth needs, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core functionality and execution behavior, the second provides essential workflow guidance. There's zero wasted language, and the most critical information is front-loaded.
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 (asynchronous simulation execution with destructive potential), the description provides good context about the execution pattern and monitoring workflow. With annotations covering safety aspects and no output schema, the description appropriately focuses on behavioral characteristics rather than return values. It could be more complete by explaining what 'destructive' entails in this specific context.
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 100% schema description coverage, the input schema already fully documents all three parameters with their types and default values. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value regarding parameter usage or semantics.
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 ('Start FDS simulation') and resource ('FDS simulation'), distinguishing it from sibling tools like bulc_get_fds_status or bulc_stop_fds. However, it doesn't explicitly differentiate from other run tools like bulc_run_evac or bulc_run_aset_analysis, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the simulation runs in background and returns immediately, and explicitly names bulc_get_fds_status as the monitoring tool. This gives good guidance on when to use this tool versus alternatives for progress checking, though it doesn't mention when NOT to use it or compare with other simulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true (indicating a potentially disruptive operation) and readOnlyHint=false (confirming this is a write operation). The description adds valuable context beyond annotations: it specifies that the tool 'sends stop signal and waits for graceful shutdown,' clarifying the operational behavior and confirming it's not an immediate kill. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the core action and behavior. Every word serves a purpose with no redundancy or fluff, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with one well-documented parameter and no output schema, the description provides adequate context about what the tool does and how it behaves. It covers the essential action and shutdown process, though it could benefit from mentioning potential side effects or error conditions given the destructive nature.
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 input schema has 100% description coverage (the 'force' parameter is fully documented in the schema). The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 ('Stop') and target ('a running FDS simulation'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'bulc_stop_evac' or 'bulc_clear_fds_data', which might handle related stopping/clearing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('running FDS simulation') and mentions graceful shutdown behavior, but doesn't explicitly state when to use this tool versus alternatives like 'bulc_stop_evac' for evacuation simulations or 'bulc_clear_fds_data' for data cleanup. No explicit exclusions or prerequisites are provided.
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?
Annotations provide readOnlyHint=false and destructiveHint=true, indicating it's a mutation tool that destroys data. The description adds valuable context beyond annotations by specifying that it 'creates optimized mesh covering all rooms and walls' and can handle multi-level buildings, which clarifies scope and behavior. It doesn't contradict annotations, as 'creates' aligns with destructiveHint=true for mesh generation.
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 well-structured in two sentences, with zero wasted words. The first sentence states the core purpose, and the second adds key behavioral details (optimization, room/wall coverage, single/multi-mesh options). Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mesh generation with 5 parameters) and annotations covering mutation/destructive behavior, the description is mostly complete. It explains what the tool does and its scope but lacks details on output (no output schema) and error handling. For a destructive tool with no output schema, it could benefit from mentioning result format or success indicators, but it's adequate for basic understanding.
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 100%, with all 5 parameters well-documented in the input schema. The description adds minimal semantic value beyond the schema, mentioning 'specified resolution' which loosely relates to cellSize and 'multi-level buildings' hinting at multiMesh. Since the schema carries the full burden, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 with specific verbs ('generate', 'creates') and resources ('FDS mesh', 'building geometry'), and distinguishes it from siblings like 'bulc_create_mesh' by emphasizing automation and optimization for all rooms and walls. It explicitly mentions multi-level building support, which differentiates it from basic mesh creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'single mesh or multiple meshes for multi-level buildings', which suggests when to use multiMesh parameter. However, it lacks explicit guidance on when to choose this tool over alternatives like 'bulc_create_mesh' or prerequisites such as needing existing geometry. No clear exclusions or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context by specifying what settings are retrieved (model type, agent parameters, stair configurations), which is useful beyond the annotations. However, it does not disclose behavioral traits like rate limits, authentication needs, or response format, which could be helpful given no output schema.
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 front-loads the purpose ('Get current EVAC simulation settings') and elaborates with specifics ('including model type, agent parameters, and stair configurations'). Every word contributes to clarity without waste, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only, non-destructive) and lack of output schema, the description is complete enough for a retrieval tool. It specifies what settings are fetched, which compensates for the missing output schema. However, it could be more complete by hinting at the return format or data structure, though this is not critical for basic 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, and schema description coverage is 100%, so there is no need for parameter details in the description. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied for zero-parameter tools, as it avoids unnecessary information.
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 action ('Get') and the specific resource ('current EVAC simulation settings'), including what those settings encompass ('model type, agent parameters, and stair configurations'). It distinguishes itself from siblings like 'bulc_get_evac_result' or 'bulc_get_evac_status' by focusing on configuration settings rather than results or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when current EVAC simulation settings are needed, but it does not explicitly state when to use this tool versus alternatives (e.g., 'bulc_get_simulation_settings' for general settings or 'bulc_set_evac_model' for setting values). No exclusions or prerequisites are mentioned, leaving usage context implied rather than explicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the purpose of returned IDs (for modify/delete operations) and implies it returns all placed furniture by default, but doesn't describe pagination behavior, rate limits, or authentication requirements. With annotations covering the safety profile, a 3 is appropriate as the description adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence states purpose and scope, second sentence provides usage guidance. Perfectly front-loaded and appropriately sized for a list operation 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?
For a read-only list tool with good annotations and full schema coverage, the description is mostly complete. It explains what the tool returns and how to use the results. The main gap is lack of output schema, so the description doesn't detail the return format structure, but this is partially mitigated by mentioning specific return attributes (IDs, positions, properties).
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 100%, so the schema already documents all three parameters with clear descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, but it implies filtering capability through 'Get a list of all placed furniture' with the schema providing the filter details. Baseline 3 is correct when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of all placed furniture' with specific attributes (IDs, positions, properties). It distinguishes from siblings like bulc_list_furniture_catalog (which likely lists catalog items rather than placed instances) and bulc_place_furniture/modify_furniture/delete_furniture (which are mutation operations rather than read operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Use the returned IDs for modify/delete operations'), which implicitly guides when to use this tool versus mutation tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives for different filtering needs, though the schema parameters suggest filtering capabilities.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the returned data fields (IDs, coordinates, thickness, height) and the purpose of IDs for subsequent operations, but it does not disclose behavioral traits like pagination, rate limits, or error conditions beyond what annotations provide.
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 front-loaded with the core purpose in the first sentence and adds a practical usage note in the second sentence. Both sentences are essential, with zero waste or redundancy, making it efficiently structured and 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 low complexity (one optional parameter, no output schema), the description is complete enough for a read-only list operation. It covers purpose, usage, and return data, but lacks details on output format (e.g., structure of the list) or error handling, which could be beneficial despite the absence of an output schema.
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 input schema has 100% description coverage, with the 'level' parameter fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as default behavior when 'level' is omitted. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get a list') and resource ('all walls') with specific attributes (IDs, coordinates, thickness, height). It distinguishes from siblings like 'bulc_create_wall' (create) and 'bulc_modify_wall' (modify) by focusing on listing, and explicitly mentions using IDs for modify/delete operations, which helps differentiate it from other list tools like 'bulc_list_rooms'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by stating 'Use the returned IDs for modify/delete operations,' which implies this tool should be used to retrieve IDs before performing modifications or deletions. However, it does not explicitly mention when not to use it or name specific alternatives, such as filtering by level vs. listing all.
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?
Annotations provide readOnlyHint=false and destructiveHint=true, indicating this is a mutation that may cause destructive changes. The description adds valuable context by specifying 'Only specified properties will be changed' (partial update behavior) and the prerequisite to get IDs from another tool. This goes beyond what annotations alone convey about the tool's operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the core purpose, the second provides essential usage guidance. Every word earns its place, and information is appropriately front-loaded.
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?
For a destructive mutation tool with no output schema, the description provides good context about partial updates and ID sourcing. It could be more complete by mentioning potential side effects or what happens to unspecified properties, but given the annotations cover destructive nature and schema covers parameters well, this is reasonably complete.
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 100% schema description coverage, all parameters are well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning room IDs come from bulc_list_rooms (implied in the schema's id description) and that only specified properties change (partial update). This meets the baseline for high schema coverage.
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 properties') and resource ('existing room'), distinguishing it from creation/deletion tools. However, it doesn't explicitly differentiate from other 'modify' siblings like bulc_modify_furniture or bulc_modify_wall, which would require 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Only specified properties will be changed' and directing users to 'Get room IDs from bulc_list_rooms first.' This gives practical guidance on prerequisites and partial update behavior. However, it doesn't explicitly mention when NOT to use this tool or name specific alternatives among siblings.
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?
Annotations indicate this is not read-only and not destructive, which aligns with the description's 'Set' action (a configuration change rather than data deletion). The description adds useful behavioral context about the default behavior for future room/wall creation, which isn't captured in annotations. However, it doesn't mention potential side effects, error conditions, or whether the change persists across sessions.
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 perfectly concise with two sentences that each earn their place: the first states the core action, and the second explains the important downstream consequence. There's no wasted language, and the most critical information (what the tool does) is front-loaded.
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?
For a single-parameter configuration tool with good annotations and full schema coverage, the description provides adequate context about the tool's purpose and behavioral impact. The main gap is the lack of output information (no output schema), but since this appears to be a simple setter command, the description's focus on the editing context is reasonably complete.
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 100% schema description coverage, the input schema already fully documents the single 'level' parameter (integer, index meaning). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without providing extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set which floor level is currently active for editing') and the resource ('floor level'), distinguishing it from siblings like 'bulc_create_level' (creates new levels) and 'bulc_list_levels' (lists existing levels). It also explains the downstream effect ('New rooms/walls will be created on this level by default'), which adds valuable context beyond just the immediate action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to change the active editing level for subsequent operations like creating rooms or walls. However, it doesn't explicitly state when NOT to use it or mention alternatives (e.g., whether you need to create a level first using 'bulc_create_level' or list existing levels with 'bulc_list_levels').
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by describing a configuration action. The description adds valuable context about the tool's purpose in simulation recording, which isn't covered by annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first defines the action and purpose, the second provides usage context. Every word contributes to understanding without redundancy or 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?
For a destructive configuration tool with good annotations and full schema coverage, the description provides adequate context about what it does and why. The main gap is lack of output information (no output schema), but the description compensates somewhat by explaining the recording purpose.
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 100% schema description coverage, the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema, so it meets the baseline but doesn't enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('configure a furniture item as an FDS thermocouple') and the purpose ('for temperature measurement... during simulation'). It distinguishes from siblings by focusing on thermocouple configuration rather than other FDS elements like detectors, fire sources, or HVAC systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('during simulation') but doesn't explicitly state when to use this tool versus alternatives like 'bulc_set_fds_detector' or 'bulc_set_fds_fire_source'. It mentions the purpose but lacks explicit guidance on prerequisites or exclusions.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds valuable context beyond annotations by specifying the coordinate system ('All coordinates are in centimeters'), which is important behavioral information not captured in structured fields. It doesn't mention side effects or permissions, but with annotations covering the safety profile, this is sufficient.
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 perfectly concise with two sentences that each earn their place: the first states the core functionality and differentiation, the second provides essential coordinate context. No wasted words, well-structured, and front-loaded with the main purpose.
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?
For a creation tool with destructive annotations and no output schema, the description provides adequate context about what it creates and the coordinate system. However, it doesn't mention what happens on success/failure or the format of any return value, which would be helpful given the absence of an output schema. Still, it's reasonably complete for the tool's 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?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description adds minimal parameter semantics beyond the schema (only mentioning 'coordinates are in centimeters', which is already implied in the schema's points description). This meets the baseline of 3 when schema does the heavy lifting.
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 specific action ('Create a room') with the distinctive feature ('with a custom polygon shape defined by an array of points'), explicitly distinguishing it from sibling tools like 'bulc_create_room' (likely for rectangular rooms) by mentioning 'non-rectangular rooms like L-shaped rooms'. It provides verb+resource+scope with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for non-rectangular rooms like L-shaped rooms'), which implicitly distinguishes it from rectangular room creation tools. However, it doesn't explicitly name alternatives or provide when-not-to-use guidance, keeping it at a 4 rather than a perfect 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating this is a destructive write operation. The description adds useful context about coordinate units (centimeters) but doesn't provide additional behavioral details like what 'destructive' means in practice (e.g., overwrites existing walls, requires specific permissions, or has irreversible effects). With annotations covering the basic safety profile, the description adds some value but not rich behavioral context.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose with essential unit information, and the second provides crucial sibling tool guidance. No wasted words, well-structured, and front-loaded.
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?
For a creation tool with good annotations (destructiveHint=true) and comprehensive schema coverage, the description provides adequate context. It covers purpose, units, and sibling differentiation. The main gap is lack of output information (no output schema exists), but for a wall creation operation, the description is reasonably complete given the structured data available.
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 100%, so all parameters are well-documented in the input schema. The description adds the coordinate unit context ('All coordinates are in centimeters') which is helpful, but doesn't provide additional parameter semantics beyond what the schema already specifies. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Create a wall segment') and resource ('between two points'), with explicit coordinate units ('in centimeters'). It distinguishes from sibling 'bulc_create_walls_rectangle' by indicating this tool is for general wall segments while the alternative is for rectangular rooms.
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 on when to use an alternative tool: 'For rectangular rooms, consider using bulc_create_walls_rectangle instead.' This directly addresses sibling tool differentiation and gives clear context for tool selection.
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?
Annotations already indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true). The description adds valuable context by specifying that coordinates are in centimeters, which is important for correct usage. However, it doesn't mention potential side effects like overwriting existing geometry or specific 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first defines the tool's function and recommended use case, the second provides critical unit information. There's no wasted language or unnecessary elaboration.
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?
For a destructive creation tool with no output schema, the description provides adequate context about what it creates and the coordinate system. However, it doesn't describe what the tool returns (e.g., wall IDs, success confirmation) or potential error conditions, which would be helpful given the destructive nature indicated by annotations.
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 100% schema description coverage, all parameters are well-documented in the schema itself. The description adds only the unit context ('All coordinates are in centimeters'), which is helpful but doesn't provide additional semantic meaning beyond what the schema already offers. This meets the baseline for high schema coverage.
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 specific action ('Create 4 connected walls forming a rectangular enclosure') and resource ('walls'), distinguishing it from siblings like 'bulc_create_wall' (single wall) and 'bulc_create_room' (room creation). It explicitly positions this as 'the recommended way to create walls for rectangular rooms,' providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('for rectangular rooms'), but doesn't explicitly state when not to use it or mention specific alternatives. While it implies rectangular scenarios, it doesn't contrast with other wall-creation methods or room-creation tools in the sibling list.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'Delete'. The description adds valuable context by specifying that wall IDs can be obtained from 'bulc_list_walls', which is not covered by annotations. It does not detail side effects like confirmation prompts or error handling, but with annotations providing safety cues, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every sentence serves a clear purpose: the first states the action, and the second provides essential usage guidance, making it highly 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?
For a destructive tool with one parameter and no output schema, the description is mostly complete. It covers the action, parameter source, and aligns with annotations. However, it lacks details on potential side effects or error conditions, which could be useful given the destructive nature, though annotations mitigate this gap.
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 input schema has 100% description coverage, with the 'id' parameter documented as 'Wall ID to delete'. The description adds minimal semantics by referencing 'bulc_list_walls' for obtaining IDs, but does not provide additional details like format or constraints beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 specific action ('Delete') and resource ('a wall by its ID'), distinguishing it from siblings like 'bulc_modify_wall' or 'bulc_create_wall'. It provides a direct reference to where to obtain the required parameter ('Get wall IDs from bulc_list_walls'), which enhances clarity and differentiation.
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 states when to use this tool ('Delete a wall by its ID') and provides a prerequisite ('Get wall IDs from bulc_list_walls'), which implies usage context. However, it does not specify when not to use it or name alternatives explicitly, such as 'bulc_modify_wall' for updates instead of deletion.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context by specifying the exact data returned (running state, progress, etc.), which helps the agent understand the output format. It doesn't mention rate limits or authentication needs, but with annotations covering safety, this provides good additional behavioral insight.
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 front-loads the purpose ('Get current FDS simulation status') and immediately details the return values. Every word adds value with no waste, making it easy for an agent to parse quickly.
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?
For a zero-parameter read-only tool with no output schema, the description is nearly complete: it clearly states the purpose and specifies the return data. It could slightly improve by mentioning if the status is real-time or cached, but given the annotations and simplicity, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, aligning with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current FDS simulation status'), specifying exactly what information is returned (running state, progress, current simulation time, estimated completion). It distinguishes from siblings like 'bulc_get_fds_data' (which retrieves data) or 'bulc_get_evac_status' (which focuses on evacuation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when checking simulation status, but provides no explicit guidance on when to use this tool versus alternatives like 'bulc_get_fds_data' or 'bulc_get_evac_status'. No exclusions or prerequisites are mentioned, leaving usage context inferred rather than stated.
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?
Annotations indicate read-only and non-destructive behavior, which the description aligns with by using 'Get'. The description adds value by specifying the types of information returned (e.g., counts, status), which annotations do not cover. However, it lacks details on potential errors or performance characteristics.
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 front-loads the core purpose ('Get general information about the current project') and lists specific data points without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
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?
For a zero-parameter read-only tool with annotations covering safety, the description provides sufficient context by detailing the information returned. However, without an output schema, it could benefit from clarifying the format of the returned data (e.g., structured object vs. plain text).
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 zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, earning a high baseline score for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'general information about the current project', specifying concrete data points like file path, modification status, and various counts. It distinguishes itself from siblings like 'bulc_get_evac_settings' or 'bulc_get_fds_data' by focusing on overall project metadata rather than specific subsystems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving project overview information but does not explicitly state when to use this tool versus alternatives like 'bulc_get_spatial_context' or other 'get_' siblings. No exclusions or prerequisites are mentioned, leaving usage context inferred rather than clearly 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?
Annotations indicate read-only and non-destructive behavior, which the description aligns with by using 'Get a list'. The description adds value by specifying the return content (mesh IDs, dimensions, cell sizes, bounding coordinates), providing useful context beyond annotations. No contradictions 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 a single, efficient sentence that front-loads the core action ('Get a list of all FDS computational meshes') and follows with specific return details. Every word contributes to understanding, with no wasted verbiage.
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?
For a read-only list tool with no parameters and no output schema, the description is nearly complete: it states the action, resource, and return data. It could slightly improve by mentioning if the list is paginated or sorted, but overall it provides sufficient context for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not need to compensate for parameter gaps, and it appropriately focuses on output semantics without redundant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get a list of all') and resource ('FDS computational meshes'), distinguishing it from siblings like bulc_delete_mesh or bulc_modify_mesh. It specifies the scope as 'all' meshes, making the purpose explicit and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving mesh information, but does not explicitly state when to use this tool versus alternatives like bulc_get_fds_data or bulc_list_result_datasets. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.
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 annotations indicate readOnlyHint=false and destructiveHint=true, which the description aligns with by implying a write operation ('Place'). The description adds valuable context beyond annotations by specifying the coordinate system ('All coordinates are in centimeters'), which is crucial for correct usage. It doesn't detail side effects like what happens if placement fails or if furniture overlaps, but with annotations covering the destructive nature, this is sufficient.
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 and front-loaded, consisting of just two sentences that directly state the tool's purpose and a key usage guideline. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient for an AI agent.
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 (10 parameters, destructive operation) and lack of an output schema, the description is reasonably complete. It covers the core action, prerequisite, and coordinate system, but could benefit from mentioning potential constraints (e.g., valid coordinate ranges) or error cases. With annotations providing safety context, it's largely adequate.
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 input schema has 100% description coverage, with each parameter well-documented (e.g., 'Catalog ID from bulc_list_furniture_catalog' for catalogId). The description adds minimal value beyond this, only reiterating the coordinate units ('in centimeters') which is already in the schema for x, y, and elevation. Thus, it meets the baseline of 3 without significantly enhancing parameter understanding.
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 specific action ('Place a furniture item') and the target resource ('at the specified position'), distinguishing it from sibling tools like bulc_list_furniture_catalog (which provides catalog IDs) and bulc_modify_furniture (which likely edits existing furniture). The verb 'Place' is precise and indicates creation/positioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by instructing to 'Get catalog IDs from bulc_list_furniture_catalog first,' which is a helpful prerequisite. However, it doesn't explicitly state when NOT to use this tool (e.g., vs. bulc_modify_furniture for editing existing items) or mention alternatives, keeping it from 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?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'without saving' (non-destructive) and 'for review' (read-only). The description adds valuable context beyond annotations by specifying that it returns the 'complete FDS input file content,' clarifying the output format, which is helpful since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose ('Generate a preview... without saving') and follow with the output detail. Every word serves a clear purpose, with no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema), the description is nearly complete: it explains the purpose, behavior, and output. However, it could slightly improve by mentioning the parameter's effect (e.g., how comments affect the preview), but this is minor given the good annotations and schema coverage.
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 input schema has 100% description coverage, with the parameter 'includeComments' fully documented in the schema. The description does not add any additional information about parameters, so it meets the baseline of 3 where the schema handles the heavy lifting.
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 specific action ('Generate a preview') and resource ('FDS input file'), and distinguishes it from siblings by emphasizing 'without saving' (unlike bulc_export_fds or bulc_save). It explicitly mentions the output ('complete FDS input file content for review'), making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('without saving' and 'for review'), implying this tool is for inspection before committing changes. However, it does not explicitly state when not to use it or name alternatives (e.g., bulc_export_fds for saving), 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a write operation that modifies state. The description adds valuable context beyond annotations by specifying the coordinate system ('All coordinates are in centimeters'), providing a unit conversion example, and mentioning the rectangular shape constraint. However, it doesn't describe what 'destructive' means in this context (e.g., whether it overwrites existing rooms at that position).
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 perfectly front-loaded with the core purpose, followed by critical context (coordinate system, prerequisite tool), and ends with a concrete example. Every sentence earns its place: the first states what the tool does, the second provides essential behavioral context, and the third illustrates usage with a realistic scenario.
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?
For a creation tool with destructive annotations and no output schema, the description provides good context: it explains the coordinate system, suggests a positioning workflow, and gives an example. However, it doesn't clarify what 'destructive' means here (e.g., whether creation fails if overlapping existing rooms) or describe the creation result format, leaving some behavioral questions unanswered.
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 100%, so the schema fully documents all 6 parameters. The description adds minimal value beyond the schema: it reinforces the centimeter unit system and provides a width/depth example, but doesn't explain parameter relationships or constraints not already in the schema descriptions. This meets the baseline for high schema coverage.
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 specific action ('Create a new rectangular room') and resource ('room'), distinguishing it from siblings like bulc_create_room_polygon (polygon-shaped) and bulc_create_walls_rectangle (walls only). It specifies the rectangular shape and coordinate system, providing precise differentiation.
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 when-to-use guidance by stating 'Use bulc_get_spatial_context first if you need to position relative to existing rooms.' This names a specific alternative tool for positioning context and establishes a clear prerequisite workflow for relative positioning 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive write operation. The description adds valuable context by specifying what gets destroyed ('furniture item') and how to obtain the required ID, though it doesn't mention permissions, rate limits, or confirmation requirements. With annotations covering the safety profile, this additional context warrants a score above baseline.
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 consists of two perfectly focused sentences with zero wasted words. The first sentence states the core purpose, and the second provides essential prerequisite information. Every word earns its place in this efficiently structured description.
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?
For a destructive operation with good annotations (readOnlyHint=false, destructiveHint=true) and complete schema coverage, the description provides adequate context. It explains what gets deleted and how to obtain the required parameter. The main gap is the lack of output schema, but the description compensates reasonably well given the tool's straightforward nature.
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 100%, with the single parameter 'id' fully documented in the schema as 'Furniture ID to delete'. The description adds marginal value by reinforcing that IDs come from bulc_list_furniture, but doesn't provide additional syntax or format details beyond what the schema already provides.
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 specific action ('Delete') and resource ('furniture item by its ID'), distinguishing it from sibling tools like bulc_modify_furniture or bulc_place_furniture. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 states when to use this tool ('Delete a furniture item by its ID') and provides a clear alternative for obtaining the required parameter ('Get furniture IDs from bulc_list_furniture'). This gives the agent complete guidance on prerequisites and distinguishes it from other furniture-related operations.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a destructive write operation. The description adds context by specifying what gets destroyed ('a room') and provides the prerequisite for obtaining the ID, which helps the agent understand the operation's impact and preparation needed. However, it doesn't mention potential side effects like cascading deletions or confirmation 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?
The description consists of two concise sentences that are perfectly front-loaded: the first states the core action, the second provides essential usage guidance. Every word serves a purpose with zero redundancy, making it highly efficient and well-structured for agent comprehension.
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?
For a destructive deletion tool with good annotations and full parameter documentation, the description provides adequate context about what's being deleted and how to obtain the required parameter. However, without an output schema, it doesn't indicate what the tool returns (e.g., success confirmation, error details), leaving a minor gap in 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?
With 100% schema description coverage, the input schema already fully documents the single parameter ('Room ID to delete'). The description adds marginal value by reinforcing that IDs come from 'bulc_list_rooms', but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Delete') and resource ('a room by its ID'), distinguishing it from sibling tools like 'bulc_delete_furniture' or 'bulc_delete_wall' by specifying the target resource type. It provides a precise verb+resource combination that leaves no ambiguity about what the tool does.
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 when to use this tool ('Delete a room by its ID') and includes a clear prerequisite ('Get room IDs from bulc_list_rooms'), which is an explicit alternative tool for obtaining the required parameter. This gives the agent complete guidance on usage context and dependencies.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a write operation ('Start'). The description adds valuable behavioral context beyond annotations: it discloses that the operation 'Returns immediately' (asynchronous behavior) and requires monitoring via another tool. No contradictions with annotations are present.
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 front-loaded with the core purpose in the first clause, followed by essential behavioral guidance. Both sentences earn their place by providing critical information without any wasted words, making it highly efficient and well-structured.
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 (a simulation starter with destructive hints) and lack of output schema, the description is mostly complete: it covers purpose, behavior, and usage flow. However, it could slightly improve by hinting at prerequisites (e.g., needing setup before running) or error conditions, though not strictly required.
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 input schema has 100% description coverage, with the parameter 'multiLevel' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 specific action ('Start evacuation simulation using JuPedSim') and resource ('evacuation simulation'), distinguishing it from siblings like bulc_stop_evac or bulc_validate_evac. It precisely communicates the core function without being vague or tautological.
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 when-to-use guidance by stating 'use bulc_get_evac_status to monitor progress,' naming a specific alternative tool for follow-up actions. This gives clear context on how this tool fits into a workflow with its sibling.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable context about the tool's role in spatial calculations and as a prerequisite for placement operations, though it doesn't detail rate limits or authentication needs.
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 front-loaded with the core purpose, followed by important usage instructions and return details. Every sentence adds value without redundancy, making it efficient and well-structured.
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 (spatial layout retrieval), the description is complete: it explains the purpose, when to use it, what it returns, and its role in workflows. With annotations covering safety and schema covering parameters, no critical gaps remain.
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 100%, with the parameter 'level' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the current spatial layout') and resource ('project including all rooms, walls, levels, and their exact coordinates'), distinguishing it from siblings like 'bulc_list_rooms' or 'bulc_list_walls' by providing comprehensive spatial context rather than just listings.
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?
Explicit guidance is provided: 'Call this first when you need to place elements relative to existing objects' with concrete examples ('next to the living room', 'above the kitchen'), and it specifies an alternative purpose ('Use this to calculate coordinates before calling create functions').
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds valuable behavioral context by specifying that it 'Returns information about what was redone', which isn't covered by annotations. However, it doesn't mention potential side effects or limitations beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve a distinct purpose: the first states the action, the second describes the return value. No wasted words or unnecessary elaboration.
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?
For a zero-parameter tool with clear annotations, the description provides sufficient context about what the tool does and what it returns. The only minor gap is the lack of output schema, but the description compensates by stating what information is returned.
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?
With 0 parameters and 100% schema coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Redo' and specifies 'the last undone operation', which distinguishes it from sibling tools like 'bulc_undo'. It's specific about what it does and differentiates from alternatives.
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 indicates when to use this tool: 'Redo the last undone operation'. This provides clear context for its application relative to the 'bulc_undo' tool, establishing a direct usage relationship.
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:

[![BULC_MCP MCP server](https://glama.ai/mcp/servers/using76/BULC_MCP/badges/card.svg)](https://glama.ai/mcp/servers/using76/BULC_MCP)

Score Badge

Copy to your README.md:

[![BULC_MCP MCP server](https://glama.ai/mcp/servers/using76/BULC_MCP/badges/score.svg)](https://glama.ai/mcp/servers/using76/BULC_MCP)

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/using76/BULC_MCP'

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