Stella MCP Server

Server Quality Checklist

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

Latest release: v0.14.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few close pairs (create_model vs build_model, add_variables vs add_stock/add_flow/add_aux) could cause slight confusion. Descriptions help resolve these overlaps, so overall the set is mostly unambiguous.
Naming Consistency4/5
Tool names consistently use lowercase snake_case with verb-first patterns (list_*, add_*, update_*, delete_*). A few longer names like sync_connectors_from_equations and auto_place_module_boxes deviate from the simple verb_noun form but remain predictable and readable.
Tool Count2/5
At 44 tools, the server is significantly over-scoped for the domain. Many tools could be consolidated (e.g., update_stock/update_flow/update_aux into update_variable, add_stock/add_flow/add_aux into add_variable), and the count exceeds the recommended range even for a complex system dynamics editor.
Completeness4/5
The tool surface covers the full modeling lifecycle: workspace management, model creation/loading/saving, variable CRUD, connector manipulation, module organization, diagram rendering, templates, simulation, and analysis. Minor gaps exist (e.g., no explicit delete_connector or get_single_variable), but these are workable via existing tools.
Average 3.7/5 across 44 of 44 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint false), but the description adds no behavioral detail beyond that. It does not disclose whether adding a flow can overwrite existing flows, whether it requires existing stocks to exist, or how the model state is affected. For a model-building operation, this lack of context could lead to misuse.
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, front-loaded sentence with no tautology or filler. It is appropriately concise, though it could incorporate a bit more context (e.g., mentioning equation or external connections) without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, nested objects, output schema), the description is too minimal. It does not convey the full range of flows (external sources/sinks, graphical functions, non_negative flag) and may mislead an agent into thinking flows only connect two stocks. The rich schema does not compensate for the lack of conceptual orientation in the description.
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 11 parameters including nested graphical_function fully described in the input schema. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline 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 ('Add a flow') and the resource ('between stocks in the current model'), distinguishing it from siblings like add_stock and add_connector. However, it narrows the scope by saying 'between stocks' when flows can also connect to external sources/sinks (from_stock/to_stock null), which is not mentioned.
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 alternative tools like add_connector or update_flow. The description lacks contextual cues or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely states the action and adds no behavioral context beyond the annotations. It does not disclose potential side effects, error conditions, idempotency, or whether existing members are preserved. Annotations indicate a mutation (readOnlyHint=false) and non-destructive intent (destructiveHint=false), but the description itself offers no extra transparency.
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 concise sentence with no unnecessary words, making it easy to parse. However, it lacks any structural elements like parameter examples or usage notes that could aid understanding without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full input schema, output schema, and annotations, the description is minimally adequate for a simple add operation. It does not, however, cover important context such as whether the module must already exist, how duplicate variables are handled, or any session/workspace requirements beyond the schema hints.
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% coverage with descriptions for all parameters, so the baseline is 3. The description adds no supplementary meaning about the parameters; it just repeats 'variables' and 'module' which are already present in the schema. No additional clarification on types, constraints, or relationships is provided.
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 uses a specific verb 'Add' with a clear resource 'variables' and target 'existing module', which conveys the core action. However, it does not explicitly differentiate from the sibling tool 'add_variables', leaving potential ambiguity about whether this tool is module-specific or model-wide.
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., module must exist, variables must already be defined) or situations where another tool like 'add_variables' or 'remove_from_module' would be more appropriate.
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?
Annotations already indicate the tool is not read-only and not destructive, but the description adds no additional context about side effects. It doesn't disclose whether existing module geometry is overwritten, whether a model must be loaded, or the scope of changes, which is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely concise and front-loaded, with no wasted words. It is appropriately sized for a simple tool, though its brevity limits the depth of information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature and six parameters, the description is too thin. It doesn't explain the layout algorithm, default behavior (all modules vs. only those with missing geometry), or any prerequisites. The output schema covers return values, but the operational context is largely absent.
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 six parameters documented, so the description adds no extra meaning beyond the schema. The baseline of 3 is appropriate since the schema carries the parameter-semantic 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 uses a specific verb 'auto-place' and identifies the resource as 'module view boxes around their member variables,' conveying a clear layout operation. However, it doesn't explicitly differentiate from sibling tools like set_module_view or render_diagram, so while clear, it's not fully distinguishing.
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, no prerequisites, and no exclusions. The schema's 'only_missing' parameter hints at a default behavior (placing all boxes) but the description itself doesn't explain when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no behavioral context such as reversibility, side effects on references, or permission requirements. It simply restates the operation without enriching the annotation-provided 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is not verbose, but it is also minimal and does not add contextual value beyond the core purpose.
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 simple nature of the tool, the presence of full schema descriptions, and an output schema, the one-line description is partially adequate. However, it omits context about module identity, scoping via model_id/workspace_id, and potential side effects of renaming, leaving some gaps for the agent.
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 four parameters individually described. The description itself adds no parameter semantics; the baseline of 3 applies because 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 ('Rename') and the resource ('existing module'). It is distinct from create/delete/add/remove module tools, though it does not explicitly differentiate from rename_variable, so it misses the full sibling distinction required for 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 does not mention prerequisites, when renaming is appropriate, or any interaction with other module operations, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false and destructiveHint=false, the description should clarify update semantics (whether partial or full replacement), but it merely repeats the title. No information about what happens to unspecified fields or how the variable is identified (via name) is provided.
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, front-loaded sentence with no word waste, making it maximally concise. It does not, however, provide the depth needed for a complex tool with nested objects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—8 parameters including a nested graphical_function object, and an output schema—a one-sentence description is insufficient. It lacks information about update behavior, required context (model_id/workspace_id), and relationship to add_aux.
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 descriptions cover 100% of parameters, including detailed explanations for model_id and workspace_id. The description adds no additional parameter meaning, but the baseline of 3 applies due to 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 states 'Update auxiliary variable fields' with a specific verb 'update' and resource 'auxiliary variable fields', clearly distinguishing from sibling tools like add_aux and update_flow. However, it does not explicitly mention that it modifies existing variables as opposed to creating them, leaving slight ambiguity.
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 add_aux or update_stock. There is no mention of prerequisites, such as the variable existing, or the distinction between creating and updating.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description's 'Add' confirms mutation. However, the description adds no extra behavioral context such as persistence, validation rules, effect on existing model elements, 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, clear, front-loaded sentence with no wasted words. It immediately conveys the tool's core purpose and is appropriately sized for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and an output schema exists, so the description need not detail return values. However, given the complexity of the graphical_function parameter and the large sibling set, the description does not provide enough contextual guidance about when or how to apply this tool 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 provides 100% coverage with descriptions for all parameters, including nested graphical_function details. The description adds only the semantic hint that an auxiliary variable is a parameter or intermediate calculation, which is useful but minimal 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 action ('Add'), the resource ('auxiliary variable'), and the target ('current model'). It distinguishes from stock/flow tools, though it could more explicitly distinguish from the sibling add_variables 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 usage guidance is provided. The description does not mention when to use add_aux versus alternatives like add_variables or update_aux, nor does it state any exclusions or prerequisites.
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?
The annotations already convey that this is destructive (destructiveHint=true) and not read-only (readOnlyHint=false). The description adds no further behavioral context, such as whether deletion is permanent, whether dependent items are removed, or what the side effects are.
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, front-loaded sentence with no unnecessary words. However, it is so minimal that it adds little value beyond the tool name, making it concise but not informationally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive and has sibling tools for module manipulation, the description lacks critical context about what happens when a module is deleted, any prerequisites, and how it differs from remove_from_module. While the annotations and schema cover some aspects, the description fails to provide a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, so by the baseline rule the score is 3 even though the tool description provides no additional parameter semantics. The description does not explain the relationship between parameters or convey any nuanced 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 'Delete a module' uses a specific verb (delete) and resource (module), making the tool's function immediately clear. It also distinguishes from sibling tools like delete_model and delete_variable by naming the specific 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 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 such as remove_from_module or delete_model. The description lacks any context about prerequisites, use cases, or situations where another tool would be more appropriate.
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?
Annotations already indicate a non-read-only, non-destructive operation. The description adds 'explicit' but does not disclose side effects, reversibility, or interaction with auto-layout behavior. Minimal additional transparency 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?
One concise sentence, front-loaded with the action and target. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description is adequate but lacks context about when manual view-box setting is needed vs automatic placement. Output schema exists, so return semantics are covered, but a bit more orientation 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%, so the schema documents all parameters. The description does not add any parameter-specific semantics beyond the schema's existing 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 uses a specific verb ('set') and resource ('view box geometry for a module'), clearly distinguishing from sibling tools like set_module_style and auto_place_module_boxes.
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 such as auto_place_module_boxes. The word 'explicit' hints at manual override but no explicit context or exclusions 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 indicate this is not read-only and not destructive; the description adds that it operates on an existing model. It does not disclose any side effects or additional behavioral context beyond the mutation.
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, front-loaded sentence with no filler. It is appropriately sized for a straightforward update 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?
Given the rich schema and output schema, the minimal description is acceptable but lacks guidance on how it fits into the simulation workflow. It does not mention that these settings are used in subsequent simulate calls.
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?
All 7 parameters are fully described in the schema, so the description adds little beyond the phrase 'simulation time settings', which only partially covers parameters like 'method' (an integration method, not a time setting). 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 tool updates simulation time settings on an existing model. It uses a specific verb and resource, though it does not explicitly distinguish it from sibling tools like 'simulate'.
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 before running a simulation. It only implies an existing model without any exclusions or workflow 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 (readOnlyHint=false, destructiveHint=false) indicate a non-destructive write, which the description aligns with. The description adds minimal behavioral context such as 'with specified time settings', but does not disclose side effects, persistence, or workspace association beyond what schema parameters imply.
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, front-loaded sentence with no filler or redundant information. It clearly states the tool's purpose without wasting 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?
Given the rich input schema (100% parameter descriptions), output schema, and annotations, the description provides adequate context for an agent to understand the tool's role. It does not explain how the model is referenced later, but the schema's parameters (model_id, workspace_id) and output schema fill that 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?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description highlights time-related settings but does not add new meaning beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and the resource (a new Stella model), with a specific scope of time settings. It is clear but does not explicitly differentiate from sibling tools like build_model, so it does not fully meet the 5-level standard.
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?
There is no guidance on when to use this tool versus alternatives such as build_model or load_template. The description implies use for creating a model but does not provide context 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?
The description aligns with the readOnlyHint=true annotation, confirming a non-mutating operation. However, it adds minimal behavioral context beyond the annotation, such as whether empty groups are included or how modules and groups are organized. This meets the baseline but doesn't enrich the agent's understanding.
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, front-loaded sentence that efficiently communicates the action and scope. There is no redundant wording; every word contributes to meaning, making it an exemplary concise 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 simple list operation with an output schema and fully documented parameters, the description is sufficiently complete. It captures the core purpose, while the schema and annotations cover return values and safety. Slight room for improvement by noting how modules/groups relate or pointing to complementary tools, but not necessary for basic 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?
The input schema provides 100% coverage for both parameters, with model_id and workspace_id clearly described. The description itself adds no parameter-level meaning, only restating the 'current model' concept already present in the schema. The baseline score of 3 is appropriate when the schema fully documents 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 a read-only enumeration of modules/groups within the current model scope, using an action verb and specific resource. It distinguishes from siblings like list_variables and list_connectors by naming the resource, but lacks additional context about the module hierarchy or relationship to other 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 such as list_variables, list_connectors, or inspect_model. There is no mention of prerequisites (e.g., having an active model) or clear scenarios where this tool is the appropriate choice.
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 a mutating operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds only the 'dependency arrow' clarification but doesn't disclose behaviors like duplicate handling, validation of variable existence, or whether existing connectors are affected. It is consistent with the annotations, so no contradiction, but the transparency is minimal.
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, front-loaded sentence with no filler. It conveys the core action and object in ten words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple write operation with full schema coverage and an output schema, so return values don't need explanation. However, the description omits usage context (when to use vs siblings) and edge-case behavior (duplicate connectors, required preconditions). It is minimally viable but not 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?
The input schema covers 100% of parameters with detailed descriptions for from_var, to_var, model_id, and workspace_id. The tool description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
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 connector (dependency arrow) between variables' – a specific verb, resource, and clarifying detail. This distinguishes it from sibling tools like add_stock or add_flow by naming the resource type and providing the dependency-direction semantics.
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 such as set_connector_routing or sync_connectors_from_equations. The description doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent without enough context to choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only and not destructive. The description provides no additional behavioral context, such as whether the current model is replaced, whether a new model is created, or any prerequisites like saving the current session. It does not contradict annotations but adds nothing 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?
The description is a single, front-loaded sentence with no filler. It communicates the essential action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and annotations that cover mutability and destructiveness, so the description does not need to describe return values. However, it lacks detail about how the load interacts with the current session (e.g., overwrites, creates new model) and does not mention any prerequisites. For a simple tool this might suffice, but there are clear 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 already documents all three parameters with full coverage (100%). The description does not add any extra meaning to the parameters, so it does not improve upon 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 ('load') and identifies the resource ('template') and the outcome ('into the current session as a model'). This clearly distinguishes it from sibling tools like list_templates, get_template_info, and save_as_template.
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 the tool is used when a template should be instantiated as a model in the current session, but it does not explicitly state when to choose this over create_model or list_templates. No alternatives or exclusions are provided.
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?
Annotations already provide readOnlyHint=false and destructiveHint=false, so the agent knows it's a safe mutation. However, the description adds no extra behavioral context beyond the name, such as whether removing also deletes the variables themselves, whether the module must exist, or any side effects on dependent components. The word 'remove' could ambiguously imply deleting variables, which is not clarified.
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 sentence with no redundant words. It is front-loaded with the verb and resource, and every word adds meaning. Efficiently communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (remove members from an existing module), and the output schema exists, so return values are not needed. However, the description omits important context such as whether the removed variables are deleted or just unlinked, and whether there are any prerequisites or side effects. This gap prevents a higher 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?
The input schema provides 100% coverage with descriptions for all four parameters (members, model_id, module_name, workspace_id), so the description carries no parameter burden. Baseline of 3 is appropriate given the schema fully handles parameter semantics.
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 ('remove'), identifies the resource ('existing module'), and specifies the object ('variables'). This clearly distinguishes it from siblings like add_to_module and delete_module, making the tool's function unambiguous.
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 you want to remove variables from a module, use this tool. However, it provides no explicit context for when to use this over alternatives, no exclusions, and no mention of prerequisites such as the module existing or the variables being present.
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=false, so the safety profile is known. The description adds no behavioral context beyond the basic action, such as whether existing files are overwritten, side effects on the in-memory model (e.g., auto_layout, resolve_layout_violations), or required permissions. It does not contradict 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 sentence that efficiently captures the core purpose without any unnecessary words. It is front-loaded with the key action and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete schema and output schema present, the description is adequate for the simple save operation, but it omits important context such as when to save (e.g., after building), whether the file is overwritten, and how 'current model' is determined. The tool has 6 parameters, so some usage context would be valuable.
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 fully documents all 6 parameters (100% coverage), so the description does not need to repeat parameter details. It adds no additional meaning beyond the schema, which is acceptable given the 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 tool saves the current model to a .stmx file, specifying the verb, resource, and output format. It distinguishes from siblings like create_model or validate_model by focusing on persistence of the existing model.
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, prerequisites (e.g., model must be built or loaded), or alternatives. It does not explain how it differs from related tools like build_model or get_model_xml for serialization purposes.
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 a write operation (readOnlyHint: false), so the description's 'set' is consistent. However, it does not explain behavioral nuances such as whether setting angle replaces existing waypoints, or how angle_locked/points_locked interact. Adds minimal 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?
Single sentence, no redundancy, efficiently states purpose.
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?
Tool has 9 optional params with multiple lookup paths (connector_uid vs from_var/to_var) and output schema exists. Description is minimal but schema and annotations compensate. However, it fails to mention required identification strategy or side effects, so not fully 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 covers all 9 parameters with descriptions (100% coverage); description adds 'and/or' combo but no additional detail. Baseline 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?
Description: 'Set connector angle and/or explicit routing waypoints' – uses specific verb 'set' and clearly identifies the resource (connector) and the attributes being modified (angle, waypoints). This distinguishes it from sibling creation tools like add_connector.
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. Description does not mention that it operates on existing connectors, nor does it contrast with add_connector or sync_connectors_from_equations.
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 a non-read-only, non-destructive operation. The description adds the contextual detail that it creates a logical grouping for variables, but does not disclose any side effects, prerequisites (e.g., requiring a model), or behavior beyond the basic create action. This is adequate but minimal, meeting the lower bar set by existing 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, concise sentence that immediately states the core function. It is front-loaded with the action and resource, with every word earning its place. No unnecessary elaboration or 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 the tool's simplicity, the 100% schema coverage, annotations, and presence of an output schema, the description is largely complete for a create operation. However, a brief note on how modules relate to other tools (e.g., 'modules can later be populated via add_to_module') would enhance completeness, so a small deduction is applied.
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 provides 100% coverage with descriptions for all four parameters (name, members, model_id, workspace_id). The tool description itself adds no parameter-specific meaning, so the baseline score of 3 is appropriate given the schema's thoroughness.
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 action ('Create') and resource ('a logical module/group'), and specifies its purpose ('for organizing variables'). This distinguishes it from sibling tools like create_model, create_workspace, and add_to_module, making the intent 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 explicit guidance on when to use this tool versus alternatives. It does not mention that add_to_module is for adding to existing modules, or that delete_module/rename_module handle other lifecycle operations. The use case is only implied by the tool name and generic purpose statement.
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 description doesn't need to restate destructiveness. It does add useful context about cleanup side effects ('clean connectors/module membership') beyond a simple delete. However, it doesn't disclose important behaviors like the constraint that stocks with connected flows require force=true (or the flows get detached), which is implied by the force parameter but not in the description. The added cleanup context earns a 3, not higher.
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 sentence that is front-loaded with the action and resource, and it includes the additional cleanup behavior succinctly. Every word earns its place; there is no fluff or repetition of schema details.
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 annotations (destructiveHint), full parameter schema coverage, and an output schema, the description provides sufficient context for a delete operation. It adds the cleanup behavior which is valuable. It could mention the force requirement, but that is already in the parameter schema. Overall, the description plus structured metadata is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – every parameter (name, force, model_id, workspace_id) has a clear description in the schema. The tool description adds no parameter-specific information beyond what the schema already provides. Per the baseline for high schema coverage, this is a 3.
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 the specific verb 'Delete' and clearly identifies the resource as 'stock/flow/aux' (variable types). It also adds the distinguishing cleanup behavior ('clean connectors/module membership'), which differentiates it from sibling tools like delete_model or delete_module. This is a clear and specific purpose statement.
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?
There is no explicit guidance on when to use this tool versus alternatives. It does not state conditions like 'use this to permanently remove a variable' or mention when not to use it (e.g., when a stock has connected flows unless force is true). The description only states what it does, not when to use it.
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 declare readOnlyHint=true, which already establishes that this is a safe read operation. The description adds the specific metadata fields returned, which is useful, but it does not disclose other behavioral traits such as pagination, volume limits, or dependencies. With annotation coverage, a baseline 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, front-loaded sentence that directly states the action and the scope of data with no redundant words. The field list is compact and informative.
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 simple read-only list operation, the description combined with the fully documented schema and output schema is sufficient. It does not explicitly mention model/workspace scoping, but the schema covers that; minor gap remains about the overall return set size or pagination behavior.
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?
Both parameters (model_id and workspace_id) have full schema descriptions, giving 100% coverage. The description adds no parameter-specific meaning beyond what the schema already provides, so it rests at the baseline.
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 ('List') and a clear resource ('connector metadata'), and enumerates the metadata fields (uid, endpoints, angle, routing lock/points), which distinguishes it from sibling list tools like list_variables and list_modules.
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 only states what the tool does; it provides no guidance on when to use it instead of alternatives like add_connector, set_connector_routing, or sync_connectors_from_equations. No context or exclusions are provided, so usage is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals that this is a safe read operation. The description adds the scope 'current session' and clarifies that only model IDs are returned, not full model details. However, it does not disclose return format, pagination, or how workspace_id affects behavior, which would be useful context given the optional parameter.
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 sentence of ten words, front-loaded with the action verb and resource. It contains no filler or redundant phrases. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the readOnlyHint annotation is present, the description is mostly sufficient. The main gap is that 'current session' is ambiguous, and the optional workspace_id parameter may modify the scope but the description does not clarify this relationship. However, the schema's parameter description partially addresses this, so the tool is still usable with less risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole parameter workspace_id, including its purpose, MCP 2026-07-28 requirement, and legacy compatibility. The tool description adds no additional information about this parameter, so the baseline of 3 for high schema coverage 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 'List' and the resource 'model IDs' within the scope of the 'current session'. This distinguishes it from sibling tools like list_variables, list_modules, and list_connectors, which target different resources. The purpose is immediately understandable.
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 is no mention of exclusions, prerequisites, or when not to use it. It simply states what it does, leaving the agent to infer usage from the name and resource type. Sibling tools like list_variables are not referenced for comparison.
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 that this is not a read-only or destructive operation, but the description adds minimal behavioral context beyond that. It does not disclose side effects such as overwriting existing templates (only visible via the optional 'overwrite' parameter) or whether the operation is reversible. This is consistent with the annotations, so 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?
The description is a single compact sentence of eight words, front-loading the action, object, and result. There is zero redundancy or filler, making it highly scannable 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?
With an output schema present and full parameter coverage in the input schema, the description is largely sufficient for a simple save operation. However, it doesn't mention that model_id defaults to the current model or that overwrite defaults to false, which are useful contextual details but not required given the schema's clarity.
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 provides full descriptions for all six parameters, so the description carries no additional parameter meaning. The baseline of 3 applies because the schema already covers all parameter semantics, and the description adds no extra insight beyond what the schema states.
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 ('Save'), a clear resource ('current model'), and a distinct artifact ('user-defined template'), which clearly differentiates it from sibling tools like save_model or list_templates. The phrase 'as a user-defined template' is specific enough to make the tool's function 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?
No guidance is provided about when to use this tool versus alternatives such as save_model or load_template. There are no usage conditions, exclusions, or references to sibling tools, leaving the agent to infer the intended context from the name and schema 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=false and destructiveHint=false, indicating a non-destructive mutation. The description adds the context that it applies to module boxes in the diagram view but does not disclose behavioral traits such as whether unspecified style properties are preserved or overwritten, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous content. It efficiently communicates the action and target.
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?
Despite the minimal description, the presence of full schema coverage, annotations, and an output schema provide a rich context. The description clearly conveys the tool's purpose. However, it does not clarify the effect on existing style settings when only some properties are provided, which prevents a perfect 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?
The input schema covers 100% of parameters with descriptions, so the description does not need to explain them. The description adds no additional parameter semantics beyond the schema, 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 action (set), the target (module box visual style), and the context (in the diagram view). This clearly distinguishes it from sibling tools like set_module_view (which likely controls viewing properties) and set_connector_routing (which affects connectors).
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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only implies usage context through its purpose statement, which is insufficient for an agent to make confident tool-selection decisions.
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 the description adds that it surfaces errors and warnings. However, it does not disclose any additional behavioral traits like whether it may be expensive or how it interacts with unsaved changes; the read-only nature is covered by the annotation.
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, directly states the action and outcome. Fully front-loaded with no filler.
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?
Tool has simple semantics, read-only annotation, and an output schema to document results. The description is sufficient but could benefit from a note on when validation is appropriate (e.g., before simulation).
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 covers 100% of parameter descriptions, including model_id defaulting to current model. The description's mention of 'current model' aligns with the schema but doesn't add new semantics beyond it.
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 uses specific verb 'Validate' and resource 'model', clearly indicating it checks for errors and warnings. It is distinct from sibling tools like inspect_model or read_model, which focus on examination rather than validation.
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 validate_model versus alternatives such as build_model or simulate. The description implies 'current model' context but does not state 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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds that it returns a structured summary and that the model_id defaults to the current model, but this is mostly reiterated from the schema. It does not disclose any other behavioral traits such as return size, performance considerations, or potential limitations, so the added value beyond annotations is modest.
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, front-loaded sentence that conveys the core purpose without any redundant words. It is concise and well-structured, with every word earning 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?
Given the presence of a full output schema, complete input schema descriptions, and the readOnlyHint annotation, the description provides sufficient context for a straightforward inspection tool. It could enhance completeness by mentioning when to prefer this over validate_model or get_model_xml, but it is not severely lacking.
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 provides 100% coverage with detailed descriptions for all three parameters, including optionality and defaults. The description does not add any parameter-specific meaning beyond what is already in the schema, landing at the 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 verb 'Return' and the resource 'structured summary of the current model', with the purpose 'for agent inspection'. It is specific and understandable, but it does not explicitly distinguish itself from sibling tools like read_model or validate_model, which could also serve inspection purposes.
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 phrase 'for agent inspection' provides a clear context for when to use this tool, implying it is for inspecting the model's current state. However, it does not mention any alternatives or exclusions, so it only partially guides the agent in 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 the description adds the behavioral scope of including both built-in and user-defined templates. There is no mention of additional behavioral traits like pagination or default sorting, but the read-only nature is clear and consistent.
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, front-loaded sentence: 'List built-in and user-defined templates'. It contains no filler, no redundancy, and succinctly communicates the core 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 simplicity, the read-only annotation, and the presence of an output schema, the description is largely complete. However, it does not explicitly mention the optional filter parameters or the fact that no filters return all templates, though the schema covers this.
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 parameters (tags, query, source) are fully described in the schema. The tool description does not add any additional parameter-level meaning, so a 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 uses a specific verb ('List') and resource ('templates'), with clear scoping to 'built-in and user-defined' categories. This distinguishes it from sibling list tools like list_variables and list_modules, making the operation unambiguous.
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 you want to list templates) but provides no explicit guidance on when not to use it or when alternatives like get_template_info or load_template might be more appropriate. No alternatives are mentioned, which limits the 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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds that it loads the file as the current model, implying a session state change, but doesn't disclose side effects such as overwriting unsaved changes to the current model or any session-specific behavior. This is minimal extra context beyond the 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, front-loaded sentence: 'Read an existing .stmx file and load it as the current model'. Every word contributes to understanding the action and outcome, with no redundant or filler content.
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 that an output schema exists and parameters are fully documented, the description covers the core purpose adequately. It could be more complete by noting what happens to the existing current model on load, but this is a minor gap given the schema annotations. The tool is part of a larger model-management set, and the description provides enough for an agent to understand basic 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% parameter coverage with descriptions for all four fields, so the baseline is 3. The description does not add any parameter-level detail beyond referencing the .stmx file, relying entirely on 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 uses the specific verb 'read' with the resource '.stmx file' and clearly states the effect 'load it as the current model'. This distinguishes it from siblings like create_model (new model) and load_template (template), and from inspect_model which does not change state.
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 opening an existing .stmx file into the session, but gives no explicit guidance on when to use this versus alternatives like create_model or load_template. It doesn't mention any exclusions or prerequisites, leaving the agent to infer from 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 already declare destructiveHint=true and readOnlyHint=false. The description adds valuable detail that all models stored in the workspace are discarded, clarifying the scope of destruction beyond the annotation. This is consistent, not contradictory.
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 action, no filler. Every word adds 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 one-parameter destructive tool with annotations and output schema, the description provides the key side effect. It could explicitly state irreversibility, but destructiveHint plus 'discard' sufficiently conveys permanence. Overall adequately 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 description coverage is 100%, and the description does not add parameter-level semantics beyond mentioning that the workspace contains models. The schema already fully documents workspace_id, so baseline 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?
Clear verb 'Revoke' with resource 'workspace' and consequence 'discard all models stored in it'. This distinguishes it from sibling tools like create_workspace and delete_model by specifying it destroys the entire workspace and its contents.
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. Although sibling tools include delete_model for individual model removal, the description does not mention that use case or any prerequisites. This is implied usage at best.
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 idempotentHint=true and readOnlyHint=false. The description adds valuable context: the mandatory pysd dependency and that integration always uses Euler regardless of the model's configured method, which affects result interpretation. 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 compact at three sentences, front-loaded with the primary action. Each sentence adds unique information—purpose, dependency, and integration method—with no redundancy or filler.
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 comprehensive input schema and existence of an output schema, the description covers the essential behavioral aspects: what it does, output format, dependency, and numerical method. It does not explain default variable selection or csv file side effects, but those are inferable from the schema, making this slightly above baseline.
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 six parameters are well-documented in the schema. The description adds no parameter-level semantics beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs the model and returns downsampled time series with per-variable summaries (initial/final/min/max). This is a specific verb+resource+output description, but it does not explicitly differentiate from siblings like sensitivity_analysis or compare_scenarios.
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?
No explicit guidance is given on when to use simulate versus alternatives. The description implies it is the basic model run tool but lacks direct instructions on selection criteria 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?
The readOnlyHint annotation already signals this is a safe read operation, and the description is consistent with that. However, the description adds no additional behavioral context beyond 'detailed metadata', such as what fields are included or error 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, front-loaded sentence with no wasted words. It clearly conveys the tool's purpose without unnecessary detail.
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 simple retrieval tool with one well-documented parameter, a readOnly annotation, and an output schema, the description is sufficiently complete. The tool's behavior and return value are covered by structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter with 100% coverage, and the description does not add meaningful extra semantics beyond reinforcing that it targets one template. Baseline 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 tool gets detailed metadata for a single template, using a specific verb and resource. This distinguishes it from sibling tools like list_templates or load_template.
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 phrase 'one template' implies the tool is for retrieving a specific template's metadata, but it does not explicitly mention when to use it instead of alternatives like list_templates. No exclusions or alternative tool references 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=false and destructiveHint=false, so the description is not burdened with that. It adds the context that the stock is added to the 'current model', but does not disclose prerequisites, side effects, or behavior beyond the schema. 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, highly concise sentence that immediately states the action, resource, and target. There is no wasted text.
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, the output schema, and full parameter descriptions, this short description is largely sufficient. It covers the core action and target. However, it does not mention any prerequisites or explicit differentiators from similar add_* tools, so it is not a 5.
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 no parameter-specific meaning beyond the schema, meeting the baseline of 3.
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 ('Add') and resource ('stock'), with a clarifying synonym ('reservoir'), and indicates the target context ('current model'). This clearly distinguishes it from sibling tools like add_flow, add_aux, and add_variables.
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: it adds a stock to the current model. However, it does not explicitly state when to use this tool over alternatives (e.g., add_aux) or mention exclusions, so it falls short of the top criterion.
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 not read-only and not destructive; the description adds valuable atomicity behavior: on any item error the model is left unchanged and the error names the failing item (stage + index). This goes beyond the structured annotation hints.
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 and front-loaded with the action and scope. The second sentence adds the critical all-or-nothing behavior without unnecessary detail.
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 and the rich input/output schemas, the description is sufficient: it states target, item types, batch nature, and error behavior. It does not need to explain return values because an output schema exists, though it could have explicitly mentioned using single-item tools for one-off additions.
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 for all 9 parameters, including per-item arrays and their nested fields. The tool description does not add extra parameter semantics beyond enumerating item types, so the baseline 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 tool adds multiple stocks, auxiliaries, flows, connectors, and/or modules to an existing model in one call. This specific verb+resource+scope distinguishes it from single-item siblings like add_stock, add_flow, add_aux, and add_connector.
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 batch use and atomicity ('in one call', 'all-or-nothing'), but it does not explicitly say when to prefer this over the single-add sibling tools or mention any exclusions. Usage guidance is therefore implied 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 declare readOnlyHint=true, so the safety profile is already covered. The description adds minimal extra behavior: it only notes the 'preview' intent. It does not disclose that auto_layout or resolve_layout_violations are performed before export, but those are visible in the schema and 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?
The description is a single, front-loaded sentence that gets straight to the point. Every word carries meaning: 'Get', 'XMILE XML representation', 'current model', and 'for preview'. There is zero filler.
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 a readOnly annotation, an output schema, and 100% schema coverage for parameters, the description is sufficiently complete for a straightforward export tool. It could improve by naming an alternative for non-preview exports, but the current level is 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?
Schema description coverage is 100%, so the parameters are fully documented in the input schema. The description itself adds no parameter-level meaning, which meets the baseline for high schema coverage but does not exceed it.
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 'Get' and names a precise resource: 'the XMILE XML representation of the current model'. This clearly distinguishes it from sibling tools like render_diagram or inspect_model, and the parenthetical '(for preview)' adds useful intent.
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 phrase 'for preview' gives a clear usage context—this is the tool to call when you need an XMILE XML preview of the model. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide basic selection among the long 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 idempotentHint=true and readOnlyHint=false, but the description does not clarify potential side effects (e.g., writing a CSV via save_sweep_csv) or the error behavior when max_runs is exceeded. It does add context about the required pysd dependency and the product (slope/elasticity), which is useful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core behavior, and includes a crucial dependency note. Every sentence earns its place 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?
For a tool with 8 parameters, nested objects, and an output schema, the description is adequate: it explains the OAT sweep method, output metric reduction, and the returned slope/elasticity. It misses the error-on-overflow behavior, but that is covered by schema descriptions. Overall, it is complete enough for an agent to invoke correctly without deep schema digging.
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 already well-documented. The description adds only high-level context (sweeping each parameter) without explaining specific parameter semantics, which is acceptable per baseline rules.
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 performs one-at-a-time sensitivity analysis by sweeping each parameter across a range while holding others at baseline, then reports how a chosen output metric responds with slope and elasticity. This specific verb+resource distinguishes it from siblings like simulate, compare_scenarios, and calibrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for OAT sensitivity analysis and explicitly notes the pysd dependency as a prerequisite. However, it does not explicitly mention alternatives or when-not-to-use, stopping short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false and destructiveHint=false. The description adds valuable context by specifying 'missing', which indicates it only adds absent connectors and does not alter existing ones. It also clarifies the inference mechanism from equations, enriching the safety profile beyond the annotation defaults.
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, tightly worded sentence that front-loads the action and object. The qualifier 'inferred from flow and auxiliary equations' is essential context, not redundant fluff, and there is no wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 optional parameters and an output schema, so the description does not need to explain return values. It covers the core behavior well, though it omits explicit prerequisites (e.g., model must exist with flows/equations). Overall, it 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both optional parameters (model_id and workspace_id), so the baseline is set at 3. The description does not add any extra parameter-level guidance, such as which parameter to use in different scenarios, but the schema itself is sufficient.
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 ('Add') and resource ('missing dependency connectors'), while also stating the inference source ('from flow and auxiliary equations'). This clearly distinguishes it from the sibling tool add_connector, which suggests manual connector creation.
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 flows and auxiliary equations are defined to fill in connector gaps, but it does not explicitly state when to prefer this over add_connector or set_connector_routing, nor does it mention any exclusions. The context is present but only implicitly.
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 not read-only and not destructive. The description adds the useful behavioral guarantee that relationships are preserved, which is beyond the schema and annotations. However, it does not elaborate on what 'preserving relationships' entails (e.g., whether non-specified fields are unchanged, or how model_id/workspace_id affect behavior). With annotations covering the basic safety profile, 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, front-loaded sentence with no wasted words. It conveys the core action and a key constraint in a compact form, making it easy to scan and understand.
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 that an output schema exists (covering return values) and the input schema fully describes parameters, the description is mostly complete. It could be improved by clarifying what fields are preserved and whether missing optional parameters are left unchanged. Still, the core operational context is sufficiently described 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 8 parameters, so the description does not need to repeat parameter details. It adds no additional semantic meaning beyond the schema, such as how parameters interact or which fields are commonly updated together. 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 verb ('Update'), the resource ('stock'), and a defining scope ('while preserving relationships'). This distinguishes it from sibling tools like add_stock (creation) and update_flow/update_aux (different target types), so the purpose is unmistakable.
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 the tool is for modifying existing stock fields without breaking connections, but it does not explicitly say when to use it over alternatives like add_stock or update_flow. It provides clear context (updates on stocks) but lacks explicit exclusions or alternative naming.
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 provide idempotentHint=true and readOnlyHint=false. The description adds behavioral context beyond that by disclosing the optional pysd dependency and the kind of results returned. It doesn't mention side effects like CSV writing, but it does surface the dependency requirement, which is useful for the agent.
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: the first conveys the core purpose and output in a dense, front-loaded manner; the second adds an essential prerequisite (pysd dependency) with an install command. No fluff, no repetition, and every sentence 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?
Given the tool's complexity (7 parameters, nested objects, output schema present), the description provides a solid high-level overview of behavior and prerequisites. The schema covers parameter details, and the output schema covers return values. The optional CSV writing is not mentioned, but that is a minor gap for a tool this well-specified.
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% parameter documentation, so the baseline is 3. The description clarifies the concept of 'scenarios' as constant overrides and explains the divergence metrics, but it doesn't add per-parameter meaning beyond what the schema already provides, so no higher score is warranted.
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 action: 'Run several named what-if scenarios against a baseline and report how each diverges'. It specifies the output (per-variable final/max absolute deltas and final percent change), distinguishing it from sibling tools like simulate or sensitivity_analysis which do different kinds of analysis.
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 gives clear context on when to use this tool: for comparing multiple named what-if scenarios against a baseline. It does not explicitly name alternatives, but the scenario-comparison focus makes the intended use evident. No exclusions are mentioned, which fits a 'clear context, no exclusions' level.
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, so safety is handled. The description adds useful context by specifying it covers stocks, flows, and auxiliaries, and that it operates on the current model. No behavioral surprises are hidden, though it doesn't mention pagination or any performance aspects.
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 concise sentence that front-loads the action and scope. Every word earns its place, with no redundancy or filler.
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 is a simple read-only list operation with full schema coverage and an output schema present, the description is sufficiently complete. It tells the user what it lists and the scope, while the output schema covers return details. Minor gaps like absence of any mention of filtering or ordering are acceptable for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (model_id and workspace_id) already described in the input schema. The description adds no additional parameter-level information, keeping the score at the baseline of 3.
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 lists all variables (stocks, flows, auxiliaries) in the current model, using a specific verb ('List') and resource ('variables'). It distinguishes from sibling tools like list_models or add_variables by specifying scope and variable types.
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 the tool: to list variables in the current model. It doesn't explicitly mention alternatives or exclusions, but given the sibling tool set, no other tool performs this exact listing function, making the usage context clear enough.
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 a non-read-only, non-destructive operation. The description adds a behavioral guarantee—preservation of structural stock links—which is valuable extra context not present in the 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, focused sentence that conveys the core purpose and a key constraint. 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?
For an update tool with a well-described schema and an output schema present, the description sufficiently covers the essential behavior. It could elaborate on prerequisites or side effects, but none are likely necessary given the annotations and 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, so every parameter is already meaningfully described. The tool description itself does not add parameter-specific semantics, so it meets the baseline but does not exceed it.
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 identifies the tool as updating flow fields, with a specific resource (flows) and action (update). The additional phrase 'while preserving structural stock links' adds distinguishing scope beyond mere naming.
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: use when updating flow fields, with the caveat that structural stock links are preserved. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to differentiate from sibling tools like update_stock or update_aux.
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 only state readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context beyond that: the returned ID routes state and is explicitly 'not an authorization credential', which helps prevent misuse. This is useful transparency without contradicting 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?
Two concise sentences that front-load the purpose and immediately follow with a critical caveat. There is no filler or redundant restatement of the tool name.
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?
The tool is simple: one optional parameter, an output schema, and clear annotations. The description covers what the tool does, when to use it, and an important behavioral warning. Nothing essential is missing for an agent to select and invoke it correctly.
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 already fully describes the only parameter (ttl_seconds) with a clear description and constraints, so schema coverage is 100%. The tool description adds no parameter-level detail, so the baseline score of 3 applies.
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 opens with a specific verb ('Create') and resource ('isolated application workspace'), and clarifies its role ('for stateful Stella tool calls'). This clearly distinguishes it from siblings like revoke_workspace and other model/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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when a stateful workspace is needed for Stella tool calls. It does not explicitly mention alternatives or exclusions, but given there is no direct create alternative, the usage context is sufficient.
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 non-read-only and idempotent, and the description adds behavioral details: returns SVG inline, may write to a file, and defaults to auto-layout. These specifics go beyond the annotation values and provide useful context about side effects and layout behavior. 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 sentences long, front-loaded with the primary purpose, and every sentence adds meaningful context. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all parameters documented in the input schema, the description covers the essential aspects: what it does, output modes, and auto-layout behavior. It is complete for a rendering tool and does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters, so the description does not need to elaborate much. It mentions file output and auto-layout conceptually, but does not add per-parameter details beyond what the schema already offers. 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 tool renders the current model as an SVG stock-and-flow diagram, specifying the output format and distinguishing itself from siblings like save_model or get_model_xml. The verb 'render' and resource 'model' are specific, and the SVG output makes 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 gives clear context: use when a visual SVG diagram is needed, with inline output for clients lacking file access and optional file writing. It mentions auto-layout for fresh models but does not explicitly name alternative tools or exclusion scenarios. Overall, the usage context is clear.
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?
Annotations already indicate destructiveHint=true, but the description adds important nuance: it only removes from the current session, not from saved .stmx files, and deliberately requires model_id (no implicit 'current model'). This goes beyond the annotation to clarify the exact scope and safety profile, which is valuable for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('Remove a model'), and every clause adds value: scope, safety, and requirement. There is no fluff or repetition.
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 simple deletion tool with full schema coverage, annotations, and an output schema, the description is sufficiently complete. It covers the essential aspects: what is removed, what is not touched, and the required parameter behavior, leaving no significant 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 model_id and workspace_id adequately described. The description adds minimal parameter-level information beyond emphasizing that model_id is required and there is no implicit fallback. This slightly reinforces the schema but does not significantly enhance meaning.
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 'Remove' with a clear resource ('a model from the current session'), and further distinguishes itself by noting that saved .stmx files are untouched and that there is no implicit 'delete current model'. This clearly sets it apart from sibling tools like delete_variable or delete_module.
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: it removes a session model only, does not affect saved files, and requires an explicit model_id. While it does not explicitly name alternative tools for other deletion tasks, the behavior and constraints are unambiguous enough for an agent to decide when to call it.
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 a non-read-only, non-destructive operation. The description adds the crucial behavioral trait that dependent references are updated automatically, which is not captured in annotations or schema. This provides valuable side-effect context beyond the structured data.
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 front-loaded sentence that efficiently communicates both the operation and its key side effect. Every word earns its place, with no redundancy or extraneous detail.
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?
The tool is simple, has 100% schema coverage, an output schema, and annotations that cover the destructive profile. The description conveys the core purpose and side effect. Potential failure conditions are likely covered by error responses given the output schema, so the description is complete enough for this 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 input schema already documents all four parameters with descriptions (100% coverage), so the baseline is high. The description adds domain context that the variable types are stock/flow/aux, clarifying that old_name and new_name refer to these specific model elements, which the schema's generic 'variable name' descriptions do not convey.
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 'rename' and the resource 'stock/flow/aux' plus the side effect 'update dependent references'. This distinguishes it from sibling tools like delete_variable and rename_module, making its 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 gives a clear context for use—when you need to rename a variable—and implicitly indicates it applies to stock/flow/aux. It does not explicitly mention alternatives or exclusions, but the context is sufficient for selecting this tool over siblings.
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?
The description discloses critical behavioral details beyond the sparse annotations (readOnlyHint=false, destructiveHint=false): all-or-nothing atomicity, error reporting that names the failing item with stage and index, default connector sync/validation behavior, and the response doubling as an inspection. This is substantial value-add.
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 compact yet information-dense: four sentences cover the tool's scope, atomicity, error granularity, and default behaviors. No filler or repetition; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (11 parameters, nested objects, output schema), the description provides enough behavioral context: scope, ordering, defaults, error semantics, and the response's role as an inspection. The presence of an output schema obviates the need to explain return structure, and sibling tool names clarify the tool's niche.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter descriptions, providing a baseline of 3. The description adds meaningful ordering semantics (e.g., 'applied after stocks', 'applied first', 'applied last') that are not in the schema, enhancing understanding of how the component arrays interact.
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 and populates a model in one call, enumerating the component types (sim specs, stocks, auxiliaries, flows, connectors, modules). This distinguishes it from sibling tools like create_model or add_stock, which handle individual steps.
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 phrase 'in one call' implies a batch alternative to incremental add tools, and the atomic all-or-nothing behavior provides contextual guidance. However, it does not explicitly name alternatives or state when to prefer this over create_model plus add_* siblings, leaving some ambiguity.
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?
Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description explains key behavioral constraints: stock calibration is disallowed and why, the least_squares method reports a linearized std_error, differential_evolution is global and seeded, and no extrapolation is allowed. These details provide substantial context that the agent could not infer from annotations or schema alone.
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 three sentences, each earning its place: the first states the core purpose and inverse relation, the second covers calibration constraints and method differences, and the third addresses extrapolation and the optional dependency. It is front-loaded with the most critical information and contains no filler or 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 the complexity (13 parameters, nested objects, output schema), the description covers the main constraints and prerequisites well. The output schema handles return values. However, there is a slight ambiguity about whether calibration persists by modifying the model's current values or just returns fitted parameters; this is hinted by 'Fit constant model parameters' and the readOnlyHint, but not explicitly stated. This small gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying method-specific parameter semantics: it notes that differential_evolution requires bounds, which ties the method enum to the 'min' parameter's optionality, and it explains the stock rejection behavior beyond the parameter array's description. This strengthens the relationship between parameters and their intended use.
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 opens with a clear verb+resource: 'Fit constant model parameters to an observed time-series' and immediately distinguishes it from siblings with 'the inverse of simulate.' This makes the tool's purpose unambiguous and differentiates it from simulate, sensitivity_analysis, and other related tools.
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 gives explicit when/when-not guidance: stocks are rejected, observation times must be within the model window, and the two optimizer alternatives (least_squares vs. differential_evolution) are described with their trade-offs (local vs. global, needs bounds). It also mentions the required pysd dependency, adding a prerequisite context. 'Inverse of simulate' makes the alternative tool explicit.
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:

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

Score Badge

Copy to your README.md:

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

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