CFAST MCP

by bewygs

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity (compartment, vent type, fire, material, device, simulation parameters, etc.) with clear descriptions. The three vent types are differentiated by their mechanics (wall, ceiling/floor, mechanical) and purposes.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case. Add/update pairs are uniform, and lifecycle tools like create_model, inspect_model, run_model maintain the pattern without mixing conventions.
Tool Count5/5
22 tools cover the full range of operations for creating, configuring, and running CFAST fire simulations. The count is well-scoped for the domain's complexity without being excessive or insufficient.
Completeness3/5
The tool surface includes create, read (via inspect/get_results), and update operations for all major components, but notably lacks delete/remove tools for compartments, vents, fires, etc. This is a significant gap for model management.
Average 4.4/5 across 22 of 22 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on June 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the output (summary string, optionally input file contents) and hints at side effects ('save the model' for show_input_file). However, it does not explicitly state that the tool is read-only or what happens if the model_id is invalid. With no annotations, the description bears full burden; it partially met it.
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 efficiently structured like a docstring with a clear summary line, parameter listing, and return type. Every sentence is necessary, and the format is front-loaded and scannable.
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 simplicity of the tool (2 parameters, no annotations, output type str), the description covers the key aspects: what it returns and the parameters. It lacks explicit error conditions or prerequisite model existence, but for this complexity level it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description fully explains both parameters: model_id as the id, show_input_file as an optional boolean with default false and behavior. This adds value beyond the schema titles. Minor confusion around 'save the model' could be clarified, but overall strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return a model summary, and optionally the CFAST input file.' The verb 'return' and the resource 'model summary' are specific, and the distinct purpose is evident among sibling tools that focus on creation, modification, or result retrieval.
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 or why to use this tool over alternatives. The description does not mention context such as 'after creating a model' or 'instead of get_results', leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like id uniqueness constraints, model mutation details, or side effects (e.g., overwriting existing material). Only parameter definitions are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections and bullet points, making it readable. While some repetition exists (e.g., parameter descriptions in docstring style), it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal), the description's mention of return as confirmation/summary/warnings is sufficient. All 8 parameters are explained, and the overall context for adding a material is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value to each parameter beyond the schema: units for conductivity, density, specific heat, thickness; default value and units for emissivity; character limit for id. This compensates for the 0% 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 tool adds a material to a model, and mentions how compartments can reference it by ID. This distinguishes it from update_material, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool before referencing materials in compartments or targets, but does not explicitly contrast with update_material or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that results are stored in the registry and returned as a bounded summary, but does not specify mutation side effects, re-run safety, or error behavior. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, no unnecessary words. Each sentence adds value: purpose, prerequisites, side effect, and return type are concisely stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, side effects, and return type for a simulation run tool. However, lacks details on error handling and validation of model existence. Given the complexity, it is fairly 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?
Schema coverage is 0%, so description must compensate. For model_id, it only repeats 'Id of the model to run.' For timeout, it adds default unit and value. This provides minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run the CFAST simulation for a model and summarize the outputs.' This provides a specific verb, resource, and outcome, effectively distinguishing it from sibling tools like get_results or create_model.
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?
Describes prerequisites (CFAST executable) and post-conditions (results stored for get_results), giving context for when to run. However, lacks explicit exclusions or comparisons to alternatives beyond mentioning get_results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It explains the None-leave-unchanged behavior and return value (confirmation, summary, warnings), but lacks details on side effects, atomicity, or prerequisites (e.g., model state). Adequate but not thorough.
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?
Structured as a summary sentence followed by parameter list with clear formatting. Somewhat verbose with redundant 'None leaves it unchanged' phrasing, but overall well-organized 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 6 parameters, no annotations, and presence of output schema, description covers parameter details well and mentions the context of a single simulation environment. Lacks behavioral constraints or error conditions, but output schema mitigates need to describe return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates with detailed parameter meanings: title character/length limits, units for time and temperatures, and scope of relative humidity. Adds significant value beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update the simulation environment (scenario and ambient conditions)' and differentiates from sibling tools by noting that a model has a single simulation environment set at create_model, making this tool unique for modifying it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises that only provided parameters are changed and None leaves them unchanged, guiding proper usage. However, it does not explicitly state when not to use this tool versus alternatives like update_compartment or update_device, though the context of simulation environment vs. compartments is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes the addition operation and explains that specifications are relative to the first compartment's floor, which is helpful. However, it lacks explicit statements about side effects (e.g., overwriting existing vents with the same id, validation of compartment overlap) or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, usage note, parameter list, and return type. It is front-loaded with key information. However, the parameter descriptions are somewhat verbose, and some details (like 'Default units: m') could be integrated into the schema or shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and a simple output schema (string), the description covers purpose, parameters, and return value adequately. It mentions the elevation overlap requirement and the 'OUTSIDE' option. Missing context includes potential error conditions, validation behavior, or interaction with other model elements, but overall it is sufficient for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only titles). The description compensates fully by providing detailed explanations for each parameter, including units (m), defaults (offset=0 m), allowed values (face choices), and the special value 'OUTSIDE' for comp_b. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a wall vent (door, window, or opening) between two compartments. It explicitly distinguishes the resource type from sibling tools like add_mechanical_vent and add_ceiling_floor_vent by focusing on physical openings that connect compartments overlapping in elevation.
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 specifies that both compartments must already exist and that comp_b can be 'OUTSIDE' for an exterior vent. It provides context for when to use (connecting overlapping compartments) but does not explicitly compare to alternative vent types or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that only provided parameters are changed (others remain unchanged) and that material_id is the selector and not modifiable. However, it does not mention permissions, side effects, or whether the update is irreversible. This is adequate but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise summary followed by a parameter list and return specification. Every section adds value. While a bit lengthy, it is appropriately sized for the tool's complexity and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter semantics, and return value. It explains the partial update behavior. Missing are error conditions (e.g., if material_id doesn't exist) and prerequisites. Overall, it is largely complete for a tool with 7 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0%, so the description compensates fully. It documents each parameter with units, default behavior (None leaves unchanged), and clarifications (e.g., emissivity is a fraction). This adds significant value beyond the schema, which lacks parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update thermophysical properties of an existing material', using a specific verb ('update') and resource ('material'). It distinguishes itself from sibling tools like 'add_material' (create) and other update tools (e.g., 'update_compartment') by focusing on material properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to modify properties of an existing material, as opposed to creating one (use 'add_material'). It does not explicitly state alternatives or when not to use it, but the context of sibling names makes the usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains parameters and return value but does not disclose side effects, error conditions, or whether the operation is reversible. Lacks behavioral details like model mutation implications.
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?
Structured with Parameters and Returns sections, front-loads purpose. Slightly verbose in parameter descriptions but each sentence provides necessary information. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter tool with no annotations and no output schema (description provides return type), the description covers purpose, all parameters, and return value. Adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully compensates. Each parameter is described with units, defaults, valid options (e.g., 'OUTSIDE'), and meaning, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and resource 'mechanical vent', specifies it is between two compartments or between a compartment and outside, and distinguishes from sibling vent tools by mentioning mechanical (fan-forced) ventilation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides precondition that compartments must exist and allows 'OUTSIDE', but does not explicitly state when to use this vs other vent types (e.g., natural vents). Offers some context but no exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is a read-only listing operation and clarifies that the directory is empty before the model is saved or run. With no annotations provided, the description carries the full burden and adds meaningful context about expected behavior.
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 main purpose, then provides usage guidance, parameter details, and return value in a clear structure. While slightly verbose, every sentence adds value and earns its place.
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?
With one simple parameter and an output schema present, the description covers the key aspects: what it does, when to use, what files to expect, and the return format. It is complete enough for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'model_id' is described in the tool description as 'Id of the model whose files to locate', adding semantic meaning beyond the input schema which only has a title. This helps an agent understand the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' and resource 'on-disk files for a model', clearly distinguishing from siblings like 'get_results' and 'inspect_model' which deal with simulation data rather than file locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: to locate input, output, and log files for opening. Also explains timing (files appear after save or run), offering context for usage. Does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the partial-update behavior (only provided parameters change), the effect of changing comp_id (moves fire, compartment must exist), and the return value (confirmation, summary, warnings). Side effects and safety are partially covered, but could be more explicit about error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, parameter list, and returns section. It is front-loaded with the core logic. While somewhat lengthy due to the parameter details, every sentence adds necessary information, making it appropriately sized for the complexity.
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 13 parameters, no annotations, and an output schema (mentioned but not shown), the description provides comprehensive information: parameter semantics, selection logic, update behavior, and return value with warnings. It leaves no major gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by providing detailed explanations for all 13 parameters, including units, optionality, and the meaning of leaving a parameter unchanged (None). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing fire' and explains the selection by instance id and partial-update semantics. It distinguishes from add_fire (create) by focusing on update, and from other update_* tools by specifying the resource (fire).
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 implicitly says when to use the tool (when updating an existing fire) but does not explicitly state when not to use it or mention alternative tools. No exclusions or context 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?
Without annotations, the description must disclose behavior. It explains partial update semantics ('changes only the parameters you provide; any left as None is unchanged') and notes that device_id is unchanged. No mention of error conditions or permissions, but basic behavioral traits are covered.
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 long for a parameter-heavy tool. It starts with a concise behavioral summary, then a structured Parameters section. No redundant information, though some units could be standardized in a separate note.
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 complexity (15 params, no annotations, output schema exists), the description is quite complete. It covers update behavior, parameter explanations, and return type. Could mention that some parameters are device-type-specific, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It provides detailed explanations for each of the 15 parameters, including units, constraints, and applicability (e.g., activation temperature for detectors). This greatly exceeds the schema which only has type info.
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 'Update an existing device (target or detector).' with a specific verb and resource. It distinguishes from siblings like add_device by focusing on updating an existing device.
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 explains that only provided parameters are changed and that device_id is the selector. It gives clear context for use but does not explicitly mention when not to use (e.g., to add a device use add_device).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details parameter behavior (None leaves unchanged, connection requires both comp_from and comp_to) and return value (confirmation, summary, warnings). It lacks information on side effects or atomicity but covers core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, parameter list, and returns section. It is fairly concise for 12 parameters, though some grouping could reduce repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, 2 required, and an output schema, the description covers all parameters with usage context and return type. Minor gaps like validation constraints do not significantly impair completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides comprehensive parameter semantics: type, meaning, default units, and usage notes (e.g., 'None leaves it unchanged', 'To change the connection, provide both'). This adds essential value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates an existing mechanical vent, selects by vent_id, and only changes provided parameters. This is a specific verb+resource that clearly distinguishes it from sibling tools like add_mechanical_vent.
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 clearly indicates when to use the tool (updating existing vents) and implies creation is done via add_mechanical_vent. However, it does not explicitly state when not to use or list alternative 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?
Since no annotations are provided, the description carries the full burden. It discloses key behaviors: material defaults, units, negative value restrictions for origins, and the return type. It lacks some details like error handling but is transparent overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro and detailed parameter list. While it is relatively long, every sentence adds value and is appropriately front-loaded. Slightly more conciseness could be achieved, but it is effective.
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 14 parameters, lack of annotations, and the presence of an output schema, the description covers prerequisites, default behaviors, constraints, and return values. It is complete and leaves no significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides extensive explanations for all 14 parameters, including defaults, units, constraints, and meaning. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a compartment to a model.' It also distinguishes from sibling tools like add_material by noting that surface materials must exist first and can be added with add_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines, such as requiring surface materials to exist beforehand and the default adiabatic behavior. It does not explicitly state when not to use the tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses prerequisites (compartment must exist, material must be added via add_material), parameter dependencies (exactly one of normal or surface_orientation for targets), and default values/units (e.g., temperature_depth default 0.5, depth_units default 'M'). It does not explicitly mention error handling or idempotency, but covers most behavioral aspects thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introductory sentence, a bullet-like list of parameters, and a return section. It is comprehensive but slightly verbose; given the complexity (15 parameters), the length is justified. It could be more concise by grouping common info, but it remains readable.
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 (15 parameters, conditional requirements, multiple device types) and the presence of an output schema, the description is remarkably complete. It covers prerequisites, parameter dependencies, default values, units, and return format. It does not delve into error cases but provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so excellently by explaining each parameter in depth: location coordinates, units, conditional requirements (e.g., material_id only for targets), default values, and the meaning of temperature_depth and depth_units. This far exceeds the minimal schema 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 tool adds a device (target or detector) to a compartment, distinguishing between target and detector types. It specifies the device subtypes (PLATE, CYLINDER, etc.) and notes the prerequisite that the compartment must already exist. This clearly differentiates from sibling tools like 'add_compartment' or 'update_device'.
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 detailed guidance on when to use each parameter based on device type (e.g., material_id for targets, setpoint for detectors). It explains which parameters are required for which type. However, it does not explicitly state when not to use this tool (e.g., for updating an existing device, use 'update_device'). The guidelines are clear but lack explicit exclusionary 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?
With no annotations, description carries full burden. It explains partial update behavior, constraints (negative origins not allowed, units in meters), and return type (string with confirmation and warnings). Lacks mention of side effects like model rebuild, but is otherwise transparent.
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?
Structured with a summary paragraph followed by parameter list. Front-loaded with purpose. While the parameter list is long, it is necessary given the schema coverage. Could slightly reduce redundancy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, 2 required, and existence of output schema, the description covers selection logic, update behavior, constraints, parameter details, and return value. Leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully. Details each parameter: width, depth, height, origins, material ids, thicknesses, with units, default (None leaves unchanged), and constraints (e.g., no negative origin_x/y).
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 'Update parameters of an existing compartment.' and explains that selection is by comp_id with partial update. It distinguishes from 'add_compartment' and other update tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: use to attach surface materials to first compartment created bare by create_model, or revise any compartment. Warns that material ids must exist (use add_material). No explicit when-not-to-use, but sufficient guidance for the main use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but the description covers what the tool does (adds a vent), parameters with defaults, and return value (confirmation, model summary, warnings). Lacks explicit mention of side effects or destructive actions, but given the nature, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured docstring with sections for description, parameters, and returns. Each sentence adds value, no redundancy. Appropriate length for the complexity.
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?
Covers all 8 parameters (5 required) with units and defaults, explains use case (vertical flow), specifies prerequisites (compartments exist), and describes return type. Complete given no annotations and no output schema in structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description provides detailed parameter documentation including units, defaults, allowed values (e.g., FLOOR/CEILING, ROUND/SQUARE), and clarifies that offsets are for visualization only. Adds full meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a ceiling/floor vent (vertical flow opening) between compartments. It distinguishes from siblings like add_wall_vent (horizontal) and add_mechanical_vent (mechanical) by specifying vertical orientation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that vents connect stacked compartments or a compartment to outside, and that compartments must exist. Does not explicitly mention when not to use or give equivalent tools, but the vertical vs horizontal distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool creates and registers the model, includes the first compartment, and returns model_id, summary, and warnings. It does not mention permissions or side effects, but for a creation tool, this is adequate 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 efficiently structured with a brief introductory paragraph, a clean parameter list with units and defaults, and a return value section. Every sentence adds value, and the length is appropriate for the tool's complexity.
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 9 parameters (5 required) and no annotations or output schema description, the description fully covers the workflow, parameter details, and return type. It explains the creation process and next steps, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed semantics for each parameter: title constraints (max 50 chars, letters/numbers/symbols), room_id uniqueness, default units for dimensions (m), default values for optional parameters (time_simulation: 900 s, etc.). This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new CFAST model with its first compartment and registers it, using the specific verb 'Create' and resource 'CFAST model'. It distinguishes from sibling tools by mentioning the workflow of using add_* tools for further elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that creation includes the first compartment because a model must contain at least one, and advises to use add_* tools for additional elements, then inspect_model and run_model. It provides clear context for usage but could explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the bounded nature ('never a full dump') and describes the return format for both cases. It does not cover auth, rate limits, or side effects, but the key behavioral trait (boundedness) is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for behavior, dependencies, parameters, and returns. Every sentence adds value; no fluff. It is front-loaded with the main purpose and bounded nature.
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 moderate complexity (3 params with conditional logic) and presence of an output schema (not shown but noted), the description covers prerequisites, parameter details, and return types completely. No gaps or ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: model_id, key (with enumerated valid values), and column (with conditional behavior and an example). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read stored run results for a model' and specifies the bounded nature, distinguishing it from sibling tools that modify or inspect models. The verb 'Read' and resource 'run results' are specific.
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 requires calling run_model first and explains when to use the optional column parameter versus omitting it. It does not explicitly state when not to use the tool or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes partial update (only provided params changed), returns confirmation string. No annotations to contradict. Lacks auth/rate limit info but sufficient for a simple update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with intro, parameter list, returns. Each sentence is informative and concise. No fluff.
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?
Covers behavior, all 8 parameters, and return value. No gaps given complexity. Output schema existing but description still explains return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Detailed parameter descriptions with constraints (e.g., for connection: need both comp_top and comp_bottom), types, units, and default behavior (None leaves unchanged). Compensates for 0% 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?
Clear statement: 'Update an existing ceiling/floor vent.' Differentiates from add_ceiling_floor_vent sibling. Specific verb and resource, with explanation of selective update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to select by vent_id and only changed parameters are updated. Implies use when modifying existing vent, not adding. No explicit alternatives but context is clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool performs partial updates, the vent_id is unchanged, and returns confirmation and warnings. It lacks details on side effects, permissions, or reversibility, but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief overview, parameter list, and return value. It is concise, front-loaded, and every sentence is informative without redundancy.
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 9 parameters, no annotations, and an output schema mentioned, the description covers purpose, behavior, parameter details, and return format completely. There are no obvious gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for each parameter: purpose, behavior on None, and constraints (e.g., both comp_a and comp_b needed for connection change). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Update' and resource 'wall vent', clearly indicating the action. It differentiates from sibling tools like 'add_wall_vent' by focusing on modification. The mention of selecting by vent_id and partial update adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states to use when updating an existing vent, with partial updates by leaving parameters as None. It implies not to use for creation (add_wall_vent) but lacks explicit alternatives or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behavioral traits: heat transfer, id-less referencing, fraction constraints for WALL vs FLOOR. Could mention whether adding overwrites or duplicates connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with brief intro, parameter definitions, and return info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, parameters, and returns. Could mention any limits on number of connections or interactions with other components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are described with detailed semantics, including constraints on fraction and role of comp_id/comp_ids for different connection types, compensating for 0% schema description 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?
Clear verb 'Add' and resource 'surface connection'. Explanation of heat transfer through solid boundaries distinguishes it from sibling tools like add_wall_vent or add_ceiling_floor_vent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (compartments must exist), gives directionality advice for WALL connections, and notes that no ID is used (refer by index).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensively discloses behavior: no id, index-based selection, only provided parameters change (others unchanged), and return value description. No annotations provided, so description carries full burden and does so effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with introductory paragraph and clear parameter list. Slightly verbose with None repetition, but overall efficient and front-loaded with key info.
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?
Fully explains all parameters, selection mechanism, and return value. Given no output schema (but annotation says it exists), the description covers what the agent needs to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes a full parameter list with explanations for each, adding significant meaning beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update an existing surface connection' and explains the index-based selection due to lack of id, distinguishing it from sibling update tools that use ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on how surface connections are selected by index and which parameters change. Could be improved by explicitly stating when not to use (e.g., if id available), but the use case is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers thorough behavioral details: time-dependent HRR specification, linear interpolation, continuation of final values, and warning if fire is outside compartment. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for parameters and return value, using bullet points and an example. While lengthy, every sentence adds value given the tool's complexity, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, complex nested data type), the description covers all parameters, explains the return value, and warns about edge cases. No gaps remain despite the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides detailed explanations for all 13 parameters, including defaults, units, and an explicit example for the complex 'data_table' parameter. This adds significant meaning beyond the schema's type 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 ('Add') and resource ('fire') and specifies the context of adding to a compartment of a model. It distinguishes the tool from the sibling 'update_fire' by indicating this is for new additions.
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 important context: the compartment must already exist, simulation interpolation behavior, and continuation of fire properties. However, it does not explicitly mention when to use this tool versus the sibling 'update_fire' or other alternatives.
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:

[![cfast-mcp MCP server](https://glama.ai/mcp/servers/bewygs/cfast-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bewygs/cfast-mcp)

Score Badge

Copy to your README.md:

[![cfast-mcp MCP server](https://glama.ai/mcp/servers/bewygs/cfast-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bewygs/cfast-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/bewygs/cfast-mcp'

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