NetLogo MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the two modes, CSV column requirements, and output effect (calibrated column in report). However, it does not mention side effects (e.g., whether it modifies the model irreversibly) or any permission requirements, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-line purpose followed by two bullet-like mode explanations. Every sentence adds value, with no redundancy. It is front-loaded with the core action and immediately clarifies optionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's conditional logic and CSV requirements, the description covers the essential usage and output effect. It does not discuss error handling or the output schema, but the latter is presumably documented elsewhere. Overall, it is sufficiently complete for an agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the conditional relationship between csv_path and campaign_name, and specifying the required CSV columns ('sent, opened, clicked, converted'), which the schema does not detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calibrates simulated funnel rates to real-world levels, and explicitly distinguishes between two modes (with and without csv_path). This specificity differentiates it from sibling tools, which are mostly about simulation and campaign management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each mode: with real stats (csv_path) or without (industry benchmarks). It implicitly tells the agent when to avoid the tool (no need if already calibrated) but does not explicitly mention alternatives. Since no sibling provides calibration, the guidance is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully discloses behavior: it discards state, resets workspace, and importantly does not shut down JVM, which is critical for understanding its effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three purposeful sentences: clear action, usage context, and a clarifying note about what it doesn't do. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters, the description covers purpose, usage, behavior, and limitations comprehensively, making it complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline applies. The description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool unloads the currently loaded model and resets the workspace, distinguishing it from siblings like open_model and create_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it (discard pending state, before opening a new model) and what it does not do (shut down JVM), providing good usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must fully disclose behavior. It states execution of a command but omits details on side effects, return values, error handling, or permission requirements. The output schema (indicated) may partially cover return values, but behavioral traits remain unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with an example list. It uses no extraneous words and communicates the tool's purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a command execution tool with one parameter and an output schema, basic purpose is clear. However, lacking usage guidelines and transparency, the description is minimally adequate but not complete for complex tasks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for its single parameter, describing it as 'The NetLogo command string to execute.' The description adds examples but no further semantic context. Baseline 3 is appropriate as schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute a NetLogo command' with examples like 'setup', 'go', 'create-turtles 10', making the verb and resource explicit. However, it does not differentiate from sibling tools like 'run_simulation' or 'set_parameter', which could also involve executing commands in broader contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 vs alternatives (e.g., run_simulation, report, set_parameter). The agent is left to infer usage from context, which may lead to incorrect selections.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It indicates the tool is read-only (comparison) but does not disclose if it has side effects, rate limits, or error conditions. It mentions requiring a previously executed campaign in the parameter description, but the main description lacks behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no wasted words. It front-loads the core purpose and efficiently conveys the relationship to get_campaign_report.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema present), the description covers the essentials: what it does, its outputs, and its relation to a sibling. It is sufficient for an agent to use correctly, though a note on error handling would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter schema coverage is 100%, and the description adds value by explaining the campaign_name must refer to a campaign already executed with run_campaign. This context beyond the schema definition helps the agent understand the prerequisite.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool does paired A/B comparison of campaign variants, listing key outputs (winner, lift, significance). It distinguishes itself from get_campaign_report by noting it's a subset for quick checks, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly positions this tool as a subset of get_campaign_report for quick checks, implying when to use it versus the full report. However, it does not provide explicit when-not-to-use or alternative scenarios beyond that one sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'create and save' but does not disclose whether the operation is mutable, idempotent, or requires specific permissions. The YAML example in the schema provides some detail but the description itself lacks transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys the essential purpose without any superfluous words. It is appropriately sized for a simple creation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of campaign creation, the description is minimal. It does not mention return values, error conditions, or prerequisites, but the schema's YAML example and the existence of an output schema partially compensate. However, more context on behavior would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter 'campaign_yaml', with a detailed YAML example. The description adds no extra parameter meaning, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb ('Create and save'), the resource ('a campaign'), and the structure ('one audience x one or more ad/email variants'). It distinguishes this tool from siblings like 'run_campaign' which likely executes a campaign, and 'compare_campaign_variants' which is for comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creation but does not explicitly state when to use this tool versus alternatives like 'run_campaign' or 'update_model'. No exclusions or prerequisites are mentioned, but the context of creation is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It explains that '.nlogox' envelope is added automatically and warns about widget variable declarations. However, it does not disclose whether the operation is destructive (overwrites existing model) or other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and well-structured. Every sentence adds value, though some widget details could be condensed or moved to schema doc. Overall efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers creating and loading but does not mention return values, error handling, or what happens with invalid code. Given the tool's complexity and many siblings, some completeness is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds significant value by explaining that 'code' can be just procedures or full .nlogox, and provides detailed examples and important caveats for 'widgets' parameter (e.g., not duplicating globals).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new NetLogo model from code and load it'), using a specific verb and resource. It distinguishes from siblings like 'open_model' and 'update_model', which are different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating models from code but does not explicitly state when to use this tool versus alternatives like 'open_model' or 'download_comses_model'. No when-not guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It extensively details safety guarantees: version resolution before cache path, HEAD request for size, stream byte cap, zip traversal validation, uncompressed size check, atomic move with marker. This goes well beyond basic transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, usage guidance, and bulleted safety guarantees. It is front-loaded but somewhat lengthy; however, the detail is justified by the tool's complexity. A slight reduction would not harm clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not needing return value explanation), the description covers all necessary aspects: purpose, usage guidance, parameter context implicitly, and extensive behavioral transparency. It is complete for the tool's complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no additional semantics beyond what the schema provides for the three parameters (identifier, max_mb, version). The safety details relate to behavior, not parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Download and safely extract a COMSES model archive' and explicitly distinguishes itself from sibling 'open_comses_model' by noting it is a standalone 'fetch but don't open' tool. This provides a specific verb+resource and differentiates from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly guides the agent: 'Most AI flows should use open_comses_model instead — it subsumes this tool and also loads NetLogo models into the workspace.' This provides clear when-to-use and alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It states the tool exports and returns an image, but does not explicitly confirm it is a read-only operation with no side effects, nor detail prerequisites like model being open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. Front-loaded with action and resource. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and no annotations, the description is fairly complete. It explains purpose and output. Could mention if image is base64 or URL, but sufficient for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema coverage, baseline is 4. The description adds context that no inputs are needed beyond the current state, which aligns with the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Export', the resource 'current NetLogo view', and the output format 'PNG image'. It distinguishes from sibling 'export_world' which likely exports state data, not an image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for visualization ('so Claude can see the model visualization'), but no explicit when-to-use or when-not-to-use compared to alternatives like 'get_world_state' or 'watch_simulation'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It discloses scope (all turtle, patch, link data) and output (returns path to CSV), but omits potential side effects or performance considerations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of output schema, the description sufficiently covers tool behavior and return value for a simple export operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the input schema, so the description adds full meaning by explaining what the export includes and the return type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool exports the full world state to a CSV file, listing the data types (turtle, patch, link) and distinguishing from siblings like export_view and get_world_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States usefulness for checkpointing or offline analysis, providing context on when to use, but lacks explicit exclusion or comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses that the tool generates and saves a synthetic audience with personas and a social network, and that it is seeded for reproducibility. However, it does not mention whether it overwrites existing audiences, authentication needs, or rate limits. The behavioral overview is decent 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a short explanation, front-loaded with the main action. Every sentence adds value, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (single parameter, no annotations), the description covers the tool's purpose, input format, and key behavioral trait (frozen/seeded). An output schema exists so description does not need to detail return values. It is sufficiently complete for an agent to understand the tool's role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and includes a detailed example in the parameter description. The main description adds context about what the YAML spec represents (audience specification) but does not significantly extend beyond the schema-provided information. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Generate and save' and the resource 'synthetic audience from a YAML spec'. It distinguishes from sibling tools like 'get_audience' (retrieval) and 'list_audiences' (listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the audience is 'frozen, seeded' and 'the same spec always produces the same people', providing strong context for when to use: testing campaign variants against identical audiences. It does not explicitly exclude alternative tools but the usage intent is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool selects N random agents from a specific breed (or all turtles when breed is None) and returns requested attributes as a markdown table. It does not mention side effects or error conditions, but the read-only nature is implied. A slight gap in explicit non-destructive guarantee prevents a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two paragraphs. The first sentence states core purpose, and the second paragraph adds context and detail. Every sentence earns its place, and the structure front-loads key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 100% schema coverage, no required parameters, and an output schema, the description is complete. It explains the tool's role relative to siblings and describes the selection logic and default attributes. No missing critical context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond what the input schema already provides for n, breed, and attributes. It restates defaults but does not introduce new parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a sample of agents with selected variables as a markdown table. It explicitly distinguishes from siblings by mentioning 'aggregates only' for get_world_state and 'hand-crafted report calls' for report, giving specific purpose context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: as a middle ground between get_world_state (aggregates) and report (custom calls). It implies when not to use by contrasting with these alternatives, making usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It only states what the tool shows, not any traits like read-only permissions, required authentication, or side effects. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero waste. Every word contributes to conveying the purpose and content of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters) and the presence of an output schema, the description adequately covers the purpose. It could mention prerequisites (e.g., audience must exist), but overall it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both parameters have descriptions in the schema). The description adds context about the output content but does not enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows a saved audience with three components (spec summary, archetypes, sample persona cards), distinguishing it from sibling tools like list_audiences (lists audiences) and generate_audience (creates audiences).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but the context implies it is for viewing details of a specific audience, contrasting with listing all audiences. No when-not or alternative tool mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. Discloses side effect: 'writes an HTML version with interactive charts.' Does not mention other traits like latency or permissions, but sufficient for a read-like operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second enumerates contents and side effect. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lists multiple report sections and side effect; output schema exists. Lacks guidance on error handling if campaign not run, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage for one parameter. Description adds context that campaign must have been previously executed with 'run_campaign,' but this is minimal extra over schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Generate the pre-flight report for a campaign that has been run.' Lists specific components (funnel, segment breakdown, etc.), distinguishing from siblings like 'report' or 'compare_campaign_variants'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States it's for a campaign that has been run; parameter description reinforces execution with 'run_campaign.' Does not explicitly exclude unrun campaigns or compare with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It only implies a read operation with 'get' but does not mention permissions, side effects, rate limits, or what 'detailed metadata' entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It is front-loaded with the verb and resource, but could benefit from brevity without sacrificing completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to detail return values. However, in the context of many sibling tools, it lacks information on what 'detailed metadata' includes and how it differs from related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already specifies 'Full UUID from search_comses results.' The tool description adds no further meaning, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and the resource 'detailed metadata for a specific CoMSES model', making the purpose unambiguous. However, it does not differentiate from siblings like search_comses or open_comses_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The sibling list includes search_comses for listing and open_comses_model for UI opening, but the description gives no context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the output format, omitting any mention of side effects, permission requirements, or that it is a read-only operation. The schema covers parameter behavior, but the description itself lacks transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately communicates the core function and use-case. It contains no filler or redundant information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and complete parameter documentation, the description is adequate but leaves gaps. It does not explain that only one attribute is returned per call (implied by 'attribute' parameter), nor does it provide usage context relative to 37 sibling tools. Overall, it meets minimum viability for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% per context signals, so baseline is 3. The description adds no extra parameter meaning beyond '2D grid' output hint; all parameter semantics are already fully documented in the input schema. The description does not compensate for any gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves patch data formatted as a 2D grid, explicitly noting its utility for heatmaps and spatial analysis. This verb+resource+use-case formulation distinguishes it from siblings like get_agent_sample or get_world_state, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for spatial/heatmap analysis via the parenthetical remark, but provides no explicit guidance on when to use versus alternatives, no exclusions, and no prerequisites. The context is implied but not systematically stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states return values, not side effects, permissions, or constraints. The read-only nature is implied but not explicit, and there is no mention of whether the tool requires an active state or model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: first states the purpose, second specifies the return structure. Every word is necessary and informative. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers what is returned, it omits important context such as prerequisites (e.g., does a model need to be open?) or any potential restrictions. Given the output schema exists, the return info is already detailed, but the description lacks completeness in guiding proper use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description does not need to add parameter documentation. Baseline for 0 params is 4. The description does not include any misleading or redundant param info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get' and the resource 'current world state', listing exact components (tick count, agent counts, world dimensions) and return format. This distinguishes it from sibling tools like get_agent_sample or get_patch_data which focus on subsets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 vs alternatives or what prerequisites are needed. Usage is implied as a general state inquiry, but without context like 'requires an open model' or 'use for overview, not details', the agent lacks clear direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It describes the action as asking a question, which implies a non-destructive read, but it fails to disclose potential side effects, error handling, or prerequisites (e.g., audience existence), leaving behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded with the core purpose. However, the word 'follow-up' may cause confusion without further context, slightly reducing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description need not explain return values. However, it omits details about error cases, the meaning of 'follow-up', and the relationship to sibling tool 'get_audience', leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter descriptions in the schema are detailed (e.g., explaining 'n' range, persona_id usage). The tool description adds no additional semantic value beyond the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'ask', the resource 'persona(s)', and provides a helpful analogy ('on-demand focus group'), making the tool's purpose immediately clear and distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like 'get_agent_sample' or 'market_info'. The term 'follow-up question' implies a prior step but is not elaborated, leaving usage context vague.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states 'list', omitting details like pagination, ordering, or whether it returns all audiences. For a list operation, such behavioral context 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (4 words) with no waste. Every word earns its place, and the information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 0 parameters and an output schema exists, the description is minimally adequate. However, it lacks context about the nature of the list (e.g., ordered, filtered) and does not help distinguish from similar list tools among siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4. The description adds value by specifying 'saved synthetic audiences', clarifying what is being listed beyond the empty schema. No further parameter info is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List saved synthetic audiences' clearly states the verb (list) and resource (saved synthetic audiences). It is specific but does not differentiate from sibling tools like 'get_audience' or 'generate_audience', though differentiation is implicitly understood from verb choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 (e.g., get_audience for a single audience). The description does not mention exclusions or context, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, but the description fails to disclose any behavioral traits beyond the action itself. There is no mention of read-only nature, ordering, pagination, or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise at one sentence. While efficient, it could include a hint about usage without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the simple nature (no params, output schema exists), the description is adequate for understanding the tool's core function given the sibling context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 parameters, 100% schema coverage). The description adds no parameter meaning, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List saved campaigns.' uses a clear verb 'List' and specific resource 'saved campaigns', distinguishing it from sibling list tools for audiences, experiments, and models.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 other list tools like list_audiences or list_experiments. The description offers no context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It discloses that reading is instant (no JVM start), that it reads without side effects, and describes the precise return format. It could be improved by explicitly stating that the tool is read-only, but the description sufficiently conveys the behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose. Every sentence adds value: purpose, mechanism, default behavior, parameter usage, and output format. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional parameter, no annotations, but detailed output), the description covers input, default behavior, output format, and edge case (empty list). It also mentions relationship to `run_experiment`, making it contextually complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description compensates by explaining that `model_path` is optional and defaults to the most recently loaded model. It gives context on when to use the parameter (to inspect a specific file), adding significant meaning beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists BehaviorSpace experiments saved inside a NetLogo model file, specifying it reads the `<experiments>` section. It distinguishes from siblings like `run_experiment` by noting it returns the list of saved experiments and mentions that an empty list means no saved experiments, but inline specs can still be passed to `run_experiment`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains default behavior (inspects most recently loaded model) and how to use the `model_path` parameter to inspect a specific file. It implies usage before `run_experiment` but does not explicitly compare to `preview_experiment` or other siblings, nor does it state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully describes the behavior: listing all .nlogo files and returning a JSON array with specific fields. It is transparent about the return format, though it omits details like potential performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that efficiently convey the tool's purpose and output without any superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the presence of an output schema, the description covers the essential behavior. It could mention edge cases (e.g., empty directory) but is largely complete for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema provides full coverage. The description adds value by detailing the output structure beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists all .nlogo model files in the configured models directory. The verb 'list', resource 'model files', and scope are specific, and it is distinct from sibling tools like create_model or open_model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives or when not to use it. While the purpose is clear, no context is given for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns status information about specific components, implying it is read-only and non-destructive. However, it does not explicitly state behavioral traits like side effects, idempotency, or performance, which is a gap given the absence of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that delivers the essential information without wasted words, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter status tool with an output schema, the description adequately lists what the status covers, providing sufficient context without needing to describe return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the schema coverage is complete. The description does not need to add parameter details, meeting the baseline expectation for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool provides the status of the market-simulation module, listing specific components like LLM config, audiences, and campaigns. It is distinct from siblings like server_info, though it could use an action verb like 'Get status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus siblings such as server_info or list_audiences. There is no comparison or context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses caching, version resolution, NetLogo file selection rules, and the exact return format with all fields. No surprises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points and clear sections. Though lengthy, every sentence adds necessary detail about behavior and return fields. Minimal redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema in the description and many sibling tools, the description covers caching, version resolution, NetLogo selection, return JSON fields, and error states (no_netlogo_file). Complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by explaining version resolution ('latest' to concrete), max_mb default behavior, and identifier as UUID. Slightly above baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool downloads/opens a COMSES model, says it's the 'single entry point', and distinguishes itself from siblings like read_comses_files and download_comses_model by detailing its unique behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('single entry point most AI flows should call'), provides specific guidance on not re-passing 'latest' in the same flow, and mentions follow-up tool (read_comses_files).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It merely states the action without revealing side effects (e.g., replaces current model, unsaved changes warning), requirements, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence without any wasted words. It is appropriately concise for a simple tool, though a bit more context would not hurt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nesting) and the existence of an output schema, the description provides the core information. However, it omits what happens after opening (e.g., the model becomes active) and any prerequisites, making it minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single 'path' parameter, so baseline is 3. The description does not add new meaning beyond the schema; it only restates the tool's purpose without elaborating on parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Open' and the resource 'existing .nlogo model file', distinguishing it from siblings like 'create_model' (which creates a new model) and 'open_comses_model' (which opens from CoMSES). It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'open_comses_model', 'create_model', or other related tools. No context about prerequisites or scenarios is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It clearly states the tool does NOT execute, only previews. It details the return JSON structure including resolved spec, total_runs, and time estimate derivation. No surprises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points and clear separation of modes. Every sentence adds value, no redundancy. Front-loaded with the key purpose. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no required ones, and presence of output schema, the description covers the essential aspects: two modes, what each returns, and the time estimate. No missing context for effective selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates well by explaining the two modes and which parameters to pass in each (experiment_name vs metrics + optional fields). However, it does not individually describe all 11 parameters (e.g., model_path, sequential_run_order). Still adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows a run plan without executing, using the verb 'show' and resource 'run plan for a BehaviorSpace experiment'. It distinguishes from sibling 'run_experiment' by explicitly advising to use it beforehand.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this before run_experiment to verify parameter combinations...' and describes two modes (by name and inline) with clear instructions for each. No ambiguity about when to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description fully discloses behavior: UTF-8 decoding with error handling, file priority order, byte cap and truncation, extension filtering, and version resolution. No behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with core purpose, then logically structured into prerequisites, important notes, and bullet-pointed behavior. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description doesn't need to detail return format, but still mentions key response fields. Covers prerequisites, all behavioral details, error conditions, and parameter usage comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and description adds significant context: explains version resolution and importance of concrete version, defaults for extensions, and cap behavior for max_total_bytes. Each parameter is enriched beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

First sentence clearly states the tool returns text contents of files from a downloaded model. Differentiates from siblings by specifying prerequisite of a prior download operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states model must be downloaded first via open_comses_model or download_comses_model, and advises using resolved_version from that call. Clearly tells when to use and prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states that the tool evaluates and returns a value, but does not explicitly clarify whether it is read-only or has side effects. Given the simplicity of the tool, the description is adequate but could be enhanced with statements about nondestructive behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and efficient. It is concise but not overly terse, providing essential information without unnecessary words. Some might argue for slight expansion on usage, but overall it is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema exists), the description is mostly complete. It covers the core functionality. However, it could briefly mention the output schema or typical return values, though that is covered by the output schema itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter description already explains the reporter expression. The tool description adds no additional meaning beyond restating the parameter's purpose, so it meets the baseline for high coverage but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'evaluate' and the resource 'NetLogo reporter expression', specifying the action and the type of input. It distinguishes from sibling tools like 'command' which executes commands without returning values, and other tools that manipulate models or retrieve data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for evaluating reporters to get values, but lacks explicit guidance on when to use this tool versus alternatives such as 'command' (for side effects) or 'get_agent_sample' (for agent data). No when-not or alternative references are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description responsibly discloses key behavioral traits: it logs every reaction, runs all variant x replicate pairs, and configures cognition via environment variable or heuristic. It does not mention side effects like overwriting previous results, but the mutation is implicit in a run tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured into three paragraphs, which is reasonably concise but includes some redundancy (e.g., 'Runs every variant x replicate' is mentioned twice). It could be tightened while retaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (not shown but indicated), the description does not need to detail return values. It covers the campaign execution model, cognition backends, and the experimental design, providing sufficient context for an agent to understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 3 parameters with descriptions, and the tool description adds context about the paired design and cognition modes but does not elaborate on individual parameters beyond what the schema already states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Run a saved campaign against its audience and log every reaction.' It specifies the verb 'run' and the resource 'campaign', and distinguishes it from siblings like run_simulation (which runs isolated simulations) and create_campaign (which saves a campaign).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool's usage context, including the paired experimental design and the two cognition modes. However, it does not explicitly state when not to use it or provide alternative tools for similar tasks, such as run_simulation for ad-hoc experiments.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: runs in separate JVM, unaffected GUI, timeouts, max runs, and return format. It lacks details on authentication or rate limits but is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for modes, variable shapes, and long-run controls. It is front-loaded with the main purpose and avoids redundancy, though slightly verbose in examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 15 parameters and no schema descriptions, the description covers most aspects: two usage modes, variable shaping, run controls, and return values. Missing details on a few parameters and no explanation of output schema, but still comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains most key parameters (metrics, variables, repetitions, etc.) with examples, but misses output_name, sequential_run_order, and run_metrics_every_step. Overall, it adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run a BehaviorSpace experiment headlessly and return summarized results,' specifying the verb, resource, and mode. It distinguishes from siblings like 'run_simulation' by mentioning headless execution and separate JVM, though no explicit differentiation is made.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains two ways to specify the experiment (by name or inline) and provides long-run controls (max_total_runs, timeout_seconds). It notes prerequisites (model file saved) but does not explicitly state when not to use the tool or suggest alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It does not mention that the run is synchronous and potentially long-running, nor does it describe state changes. This is insufficient for a tool that likely blocks and modifies simulation state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and concise. It is efficient but could add a bit more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description does not explain what the tool returns (e.g., a table of reporter data per tick). Given the complexity of parameters like max_rows and summary_only, more context on output behavior is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal value by linking 'N ticks' to the ticks parameter and 'collect reporter data each tick' to reporters, but the schema already defines these well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'run', the resource 'simulation', and the scope 'for N ticks and collect reporter data each tick'. It clearly distinguishes from siblings like 'command' (single command) and 'run_experiment' (multiple simulations).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a simulation with specific ticks and reporter collection is needed, but it provides no explicit guidance on when not to use this tool, nor does it mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries full burden. It discloses key behaviors: code can be procedures-only or full XML, envelope is added automatically, and widgets follow create_model schema. However, it does not mention whether it overwrites existing files, permission requirements, or any side effects beyond saving.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences, each serving a clear purpose. The first sentence states the core action, the second provides usage context for desktop visualization. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description need not detail return values. It covers the main aspects: saving to a specific directory, automatic envelope addition, and widget schema. However, it lacks information on overwrite behavior, error handling, or success indicators, which might be relevant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, baseline is 3. The description adds significant value beyond the schema: clarifications for code (procedures vs. XML, automatic envelope), name (without extension), and widgets (relationship to create_model, caution about globals). This enriches understanding of parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: saving NetLogo model code to a .nlogox file in the models directory. The verb 'save' and resource 'model code' are specific. It distinguishes from siblings like create_model or update_model by focusing on saving to file for desktop use, though not explicitly differentiating from all siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly suggests usage when you want to open the model in the NetLogo desktop app for live visualization. However, it does not provide explicit guidance on when not to use this tool versus alternatives like create_model or update_model, nor mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It does not disclose behavioral traits beyond the schema's parameter descriptions—e.g., pagination details or that leaving query empty browses all models. The schema partially compensates, but the description adds no new safety, auth, or rate-limit context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded with the key action, but a bit more context could improve without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with complete schema and output schema, the description is adequate but not rich. It misses usage guidelines and behavioral context that would help in a toolset with many related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing clear explanations for 'page' and 'query'. The tool description adds no additional meaning beyond the schema, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Search' and identifies the resource as 'the CoMSES Net computational model library,' making its purpose clear. It distinguishes from sibling tools like get_comses_model (specific model retrieval) and download_comses_model (download), though it could be more explicit about the query-based nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 open_comses_model or get_comses_model. It lacks any 'when to use' or 'when not to use' context, which is needed given the number of sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: it's a pure config/filesystem inspection with no JVM round-trip and works pre-initialization. It could still mention that it's safe and read-only, but the provided details are strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs. First sentence states purpose, second explains utility and return fields, third adds technical detail. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema available, the description fully covers the tool's purpose, behavior, and return types. The explanation of its lightweight nature and pre-initialization capability adds completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description adds value by listing what the output contains, which compensates for the absence of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a snapshot of the server's configuration, listing specific fields (version, paths, GUI mode, model, headless launcher). It is distinct from siblings like 'report' or 'command' which focus on model interaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description frames the tool as a 'no-cost health check' and notes it works before workspace initialization. However, it does not explicitly mention when not to use it or compare it to alternatives, which would improve guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as mutation, side effects, or safety. It only restates the purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at one sentence with no wasted words, but it lacks structure that could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a setter with output schema, the description omits behavioral context like return value or side effects, leaving gaps for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set') and the resource ('NetLogo global variable / slider / switch value'), distinguishing it from sibling tools like 'command' and 'report'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for setting parameters but provides no explicit guidance on when to use vs alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the mutation behavior: 'rewritten' and 'reloaded' the .nlogox file, and that widgets are 'preserved unchanged' when omitted. This goes beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, followed by the benefit over the alternative. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple 2-parameter schema and presence of an output schema, the description covers purpose, usage, behavioral effects, and parameter default behavior (widgets preserved). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for both parameters. The tool description adds some context (e.g., 'in place' implying file rewriting) but does not significantly enhance the meaning of individual parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Update') and resource ('currently loaded model's code'), and explicitly distinguishes it from the sibling 'create_model' by stating when to prefer this tool ('when iterating on an existing model').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to 'Prefer this over create_model when iterating on an existing model', providing a clear use case and rationale (same file rewritten, window stays on model, no directory growth).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It explains that the tool steps 'go' once per tick with a pause, and that it works but is pointless in headless mode. However, it does not explicitly state that it returns no data (unlike run_simulation) or mention any side effects. Still, the behavioral description is largely adequate and truthful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs with the key point in the first sentence. Every sentence serves a purpose: stating the primary function, comparing with the sibling, specifying use cases, and noting headless mode. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 params, high schema coverage, output schema present), the description covers the essential behavioral and usage aspects. It explains the slow stepping, the pause, the headless caveat, and the target audience (demos, teaching). Lacking only a brief note on return value (likely nothing or a status), but not a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reinforces parameter usage (e.g., 'pause between steps' maps to delay_ms) but adds little beyond the already-detailed schema descriptions. For example, the schema already explains the 120-second constraint on delay_ms. No new semantic insight is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Run the simulation SLOWLY so a human can watch it in the GUI window,' clearly stating the verb (run), resource (simulation), and key distinguishing trait (slowness for human viewing). It contrasts with sibling 'run_simulation' by noting the speed and data-return difference, making the tool's unique role unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly compares with 'run_simulation' and gives clear usage context: 'use it for demos and teaching when the user wants to see the dynamics unfold live.' It also warns against headless mode: 'In headless mode it works but there's nothing to watch; prefer run_simulation there.' This provides direct when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.