pns-server MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with detailed descriptions that differentiate similar patterns (e.g., add_queue variants, add_conveyor vs add_conveyor_line). A few pairs like add_batch and add_timed_batch could cause minor confusion but are well-documented.
Naming Consistency5/5
The naming is fully consistent, using snake_case throughout with a clear verb_noun pattern (add_*, connect_*, modify_*, remove_*, etc.). All tool names follow predictable conventions without mixing styles.
Tool Count4/5
66 tools is high, but justified for a comprehensive Petri net modeling tool. The count reflects the many pattern variants and low-level operations needed. However, some users might find it overwhelming, so it's slightly above ideal.
Completeness5/5
The tool set is exceptionally complete, covering creation, modification, connection, layout, simulation, validation, and export. It includes a wide range of high-level patterns and low-level primitives, leaving no obvious gaps in the modeling workflow.
Average 3.6/5 across 66 of 66 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, permissions, or dependencies; the agent receives no information about what happens when adding a balking queue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to be concise because it omits essential information; every sentence should earn its place, but this single sentence provides negligible value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, an output schema, and many similar sibling tools, the description is grossly incomplete; it does not enable correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no information about parameters like capacity, service_time, or distribution; the agent must guess their meanings from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add balking_queue pattern' uses a verb and a resource, but 'balking_queue pattern' is not explained; it does not differentiate from many similar sibling tools like add_bounded_queue or add_finite_population_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other queue-related add tools; no contextual hints or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits, but it only states the action without any details on side effects, resource requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (3 words), which could be considered concise, but it sacrifices necessary information. It is front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is completely inadequate. It fails to explain what the tool does, when to use it, or how parameters affect behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters 'name' and 'capacity'. The default of capacity=1 is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add bounded_queue pattern' vaguely indicates the action and object but lacks specificity. It does not explain what a 'bounded_queue pattern' is or how it differs from similar tools like add_balking_queue or add_finite_population_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description gives no context about prerequisites, scenarios, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It says nothing about side effects, whether the tool creates a new network element, or any required prior states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but not appropriately sized because it omits critical information. It is under-specified rather than efficiently compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no parameter descriptions, the description is grossly incomplete. The tool's purpose, behavior, and usage are not adequately explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters. The agent receives no help understanding what 'timeout', 'service_time', etc., mean in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it adds a reneging queue pattern but does not define what a reneging queue is or how it differs from sibling tools like add_balking_queue or add_retrial_queue. It is too vague for an agent to correctly select this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. No prerequisites, context, or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or destructive nature. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short, the description is under-specified, not concise. It lacks essential information, making it unhelpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one param, output schema exists), the description is still inadequate. It does not explain the tool's role, return value, or how it fits with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' has no description in the schema (0% coverage) and the tool description adds no meaning. The agent gets no help understanding what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add terminator pattern' is vague; 'terminator pattern' is unclear and does not distinguish from many sibling 'add_*' tools like add_arc or add_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool versus alternatives. The description is too minimal to provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information. It does not disclose what the tool modifies, whether it requires authorization, or any side effects. The single sentence offers no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is unhelpful due to under-specification. Conciseness without informativeness is not valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and an output schema, yet the description provides no context about the return value, behavior, or how the pattern interacts with the system. It is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage, and the description does not explain any parameters. The agent gains no understanding of parameter semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add scheduled_availability pattern', which is a verb plus resource but lacks specificity. It does not explain what a scheduled_availability pattern is, and the sibling tools are similarly named, so this does not distinguish the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description provides no context about prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits, side effects, prerequisites, or effects on the system. The agent has no insight into what happens when adding a timed_batch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of informativeness. It is under-specified, providing only a single phrase that repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five parameters and lack of schema descriptions, the description is entirely insufficient. An output schema exists but is not utilized. The tool is part of a large set of similar 'add_*' tools, yet no differentiation is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description adds no meaning beyond property titles (e.g., name, batch_size), leaving the agent without guidance on valid values or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add timed_batch pattern,' which is a verb+resource but lacks any explanation of what a timed_batch is or how it differs from sibling tools like add_batch. It is vague and provides no scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Without differentiation from siblings (e.g., add_batch), the agent cannot determine appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a terse description, the tool's behavioral traits are unknown. It implies mutation ('add') but provides no details on side effects, permissions, or what happens to existing elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), but this brevity comes at the cost of clarity. It is under-specified rather than genuinely concise, scoring 2.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many siblings, output schema present), the description is grossly incomplete. It lacks any context about the output, prerequisites, or how the buffer integrates into the network.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'name' has no description in the schema (0% coverage) and the tool description adds no meaning. The agent has no information on what the name represents or how to choose it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add buffer pattern' clearly identifies the action (add) and the object (buffer pattern), but fails to explain what a buffer pattern is in this modeling context. It is minimally sufficient but vague, scoring 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines provided on when to use this tool versus its many siblings (e.g., add_arc, add_machine). This absence makes it difficult for an AI agent to select the correct tool without trial and error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as side effects, prerequisites, or outcomes. It merely states the action without any operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but lacks essential information, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and a complex simulation context, the description is severely incomplete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the 8 parameters. The agent receives no assistance in understanding parameter meanings or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'add' and the resource 'blocking_machine pattern,' but does not explain what a blocking_machine is or how it differs from siblings like add_machine or add_preemptive_machine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; the description is a single phrase with no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, prerequisites, or whether it modifies existing elements. For a tool that likely creates a breakdown pattern, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks essential information. It is under-specified rather than concise, failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and 0% schema description coverage, the description is completely inadequate. Although an output schema exists, the description does not mention return values or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 7 parameters. The schema only lists names and defaults, so the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add breakdown pattern,' which is a verb+resource but lacks specificity about what a breakdown pattern is. It distinguishes from siblings like add_machine but doesn't clarify the concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No exclusions or prerequisites are mentioned, leaving the agent to infer from domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose any behavioral traits, such as side effects, creation details, or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, the single sentence is under-specified and provides no structure or front-loaded information. It sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, many siblings) and lack of annotations or schema description, the description is completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the 8 parameters. It does not explain the purpose of parameters like 'distribution', 'channels', or 'time_unit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add preemptive_machine pattern' is almost a tautology, restating the tool name without explaining what a preemptive machine is or how it differs from siblings like 'add_machine' or 'add_blocking_machine'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes many similar 'add_*' tools, but 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond the tool's name. With no annotations, the agent cannot infer side effects, permissions, or whether the tool modifies existing elements or creates new ones. This is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices necessary detail. Conciseness should not come at the expense of clarity; the tool's purpose and usage are underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters with no schema descriptions, no annotations, and many similar sibling tools, the description is severely incomplete. It fails to provide essential context about what a server vacation pattern is, how it behaves in the network, or what the output schema contains (though output schema exists, it is not described).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the 8 parameters. Parameter names like 'threshold', 'distribution', and 'processing_time' are self-explanatory, but their specific roles in a server vacation pattern are unclear. The agent has no guidance on valid values or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add server_vacation pattern,' which provides a verb and resource, but the term 'server_vacation pattern' is domain-specific and not explained, leaving its purpose vague. Among many 'add_*' siblings, it fails to differentiate itself from similar tools like 'add_breakdown' or 'add_setup_machine'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are no prerequisites, exclusions, or context signals indicating the appropriate scenarios for adding a server vacation pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states that it adds a pattern, with no mention of side effects, prerequisites, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise at three words, the description is under-specified. It sacrifices informativeness for brevity, offering no real value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no schema descriptions, and no annotations, the description is severely incomplete. The output schema exists but is not leveraged in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters have no descriptions. The description adds nothing about the meaning of fields like 'setup_time', 'processing_time', or 'distribution', leaving them completely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add setup_machine pattern' is vague; it does not explain what a 'setup machine' is or its role. With many sibling tools like 'add_machine' and 'add_preemptive_machine', it fails to differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes many similar tools, but 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses no behavioral traits such as side effects, permissions, or what happens when adding a batch pattern. The minimal description does not add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), but it is under-specified. It lacks necessary information to be useful, so it fails the conciseness quality of being both brief and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many siblings, two parameters, output schema exists), the description is grossly incomplete. It provides no context about output, usage, or how it fits into the broader toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the parameters 'name' and 'batch_size'. It does not explain their purpose or expected values, leaving the agent without helpful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add batch pattern' uses a verb and resource, giving a general idea, but it is vague and does not distinguish from sibling tools like 'add_timed_batch' or 'add_assembly'. It lacks specificity on what a batch pattern is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. With many similar 'add_*' siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Add retrial_queue pattern' without explaining side effects, prerequisites, or the nature of the operation (e.g., creates an element in a network). This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than efficiently informative. It lacks structure and essential details, making it insufficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0% schema description coverage, and many sibling queue types, the description is grossly incomplete. It does not explain the retrial queue behavior, network context, or return values (output schema exists but is not elaborated).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention any parameters (e.g., name, service_time, retrial_delay) or their meanings. It fails to add semantic value beyond the bare schema, leaving the agent with no understanding of parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add retrial_queue pattern' specifies a verb and resource, but 'pattern' is vague and does not clarify what a retrial queue is or how it differs from siblings like add_balking_queue or add_reneging_queue. It is minimally clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling add_ tools for different queue types, the absence of usage context makes selection difficult for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action without mentioning side effects, permissions, or outputs, offering minimal transparency about what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it is too sparse given the tool's complexity. It could be expanded slightly without losing efficiency, balancing brevity with usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has six parameters with no documentation. The description does not provide enough context for an agent to invoke it correctly, especially without parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It adds no meaning beyond the schema, failing to explain the purpose of 'name', 'threshold', 'queue_place_id', etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool adds a 'threshold_activation pattern,' which clarifies the verb and resource. However, it does not explain what a threshold_activation pattern is or how it differs from other 'add' tools, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like add_arc or add_machine. The description lacks context about prerequisites or scenarios, providing no help for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Add feedback_loop pattern,' which implies a creation operation, but lacks details on side effects, required prerequisites, or whether it is idempotent. With no annotations, the description carries the full burden, which it fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but it is under-specification rather than conciseness. It fails to provide necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotation, no schema parameter descriptions, and a minimal description, the tool definition is grossly incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the sole parameter 'name,' and the description does not clarify its meaning or expected format. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add feedback_loop pattern' clearly states the action and the resource, but it does not provide any additional context to distinguish this tool from its siblings beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other 'add_*' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as side effects, idempotency, or prerequisites. For a creation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is underspecified rather than concise. Every word should earn its place, but 'Add quality_check pattern' lacks necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter, existence of an output schema, and many sibling tools, the description is inadequate. It does not explain the return value or how this pattern fits into the broader network.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds no meaning to the required 'name' parameter. The agent has no idea what the name refers to or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add quality_check pattern' clearly states the action (add) and the resource (quality_check pattern), but it does not differentiate this tool from siblings such as add_arc or add_machine, so it lacks distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, when not to use it, or alternatives. The agent has no context to decide between this and similar add_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, errors, or impact on the network. It only describes the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences and clear parameter documentation. It is front-loaded with the purpose and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (many sibling connect and add tools), the description lacks context on how this tool differs, prerequisites, or what the output schema provides. It is minimal and does not cover all needed information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining each parameter's role ('Output place ID from the source pattern', 'Input place ID of the target pattern'), but the explanations are somewhat vague and lack further detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects the output of one pattern to the input of another, using specific verbs and resources. However, it does not explicitly differentiate from other connect tools like connect_blocking_consumer, but the focus on 'patterns' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'remove', implying deletion but no details on side effects, requirements (e.g., arc must be disconnected), or return value. Output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short description with structured Args section. Front-loaded, no wasted words. However, it is too brief to cover necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple tool with one param and output schema, description lacks prerequisite info, effect on net state, and return value. Incomplete for safe usage in a complex modeling environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The docstring says 'arc_id: ID of the arc to remove' which adds minimal context beyond the schema (string). No explanation of what constitutes an arc ID or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Remove a single arc from the Petri net.' Verb 'remove' with specific resource 'arc' and context 'Petri net' clearly distinguishes from siblings like add_arc and modify_arc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., modify_arc, remove_place). No mention of prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, prerequisites (e.g., workstation existence), or result behavior. The description is minimal beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences and a parameter list. It front-loads the purpose and uses no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema and clear sibling alternatives, the description is minimally adequate. It could be improved by mentioning what happens if workstations don't exist or what the output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameter names but adds no extra meaning such as format, constraints, or examples beyond the input schema. Schema coverage is 0%, and the Args section merely repeats the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it connects the bypass output of one workstation to the input of the next, using specific verb and resource. It distinguishes from sibling tool add_conveyor_line by noting it is a manual alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends using add_conveyor_line instead for automatic connections, providing clear guidance on when to prefer an alternative. It does not explicitly state when to use this tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the transformation logic (weight=1 to weight=N) and use cases, but does not mention safety aspects like whether the tool modifies the model, if it's idempotent, or potential side effects. The behavioral description is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured, starting with a clear pattern name and including a visual structure representation. The use case list is helpful but adds length. Overall, it's efficient with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (which covers return values), the description adequately explains the main behavior and provides use cases. It does not discuss error conditions or edge cases, but for a modeling tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly explains 'batch_size' through the transformation description ('batch_size individual tokens'), but 'name' is not described. The description adds some context but does not fully detail the parameters, leaving ambiguity about what 'name' represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to expand one token into multiple tokens (unbatch/split). It provides concrete use cases and explicitly positions it as the inverse of 'Batch', which differentiates it from sibling tools like add_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'The inverse of Batch' and lists use cases, giving clear context on when to use the tool. However, it does not explicitly state when not to use it or compare to other splitting tools, though the contrast with add_batch is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description does not explicitly state read-only nature, safety, side effects, or auth requirements. Only says it returns formatted statistics, missing behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core purpose, no redundant or missing words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no parameters and existing output schema; description covers core function adequately, though could mention whether results persist after retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so schema coverage is complete. Description adds context about return format, meeting the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies exact verb 'Get' and resource 'results of last simulation run', clearly distinguishing it from sibling tools like run_simulation and other add/modify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (must be called after run_simulation), but no explicit prerequisites, when-not-to-use, or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It explicitly warns 'WARNING: Destructive — the transition and ALL arcs connected to it are deleted', which is a strong behavioral disclosure. However, it does not mention return values 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, one for warning, and one for parameter. It is front-loaded with the key action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple removal tool with an output schema. It covers the destructive behavior and the parameter. Slight gap: no mention of return value, but output schema may handle that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It describes the sole parameter as 'ID of the transition to remove', which adds basic meaning but is minimal. A 3 is appropriate given the compensation is present but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Remove a transition' and the resource 'from the Petri net', specifying that all connected arcs are also deleted. This distinguishes it from sibling tools that modify or add elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remove_arc or other removal tools. The description implies use when deleting a transition but does not provide context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it does not mention prerequisites (e.g., workstations must exist), side effects (e.g., arc creation), or constraints on use. The description only states the basic action and parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences followed by a parameter list. It front-loads the purpose and is free of unnecessary information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are not needed. However, the description lacks details about state changes (e.g., arcs created), prerequisites (existing workstations), and potential interactions with other network elements. This leaves gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It lists parameters with defaults and time unit options, adding meaning beyond the schema. However, it does not explain the context of 'return_delay' or the significance of the time unit options, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create return loop from last workstation back to first.' It includes a specific verb and resource, and distinguishes itself from the sibling tool 'add_conveyor_line' by recommending that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to prefer 'add_conveyor_line' which creates return loops automatically, providing clear guidance on when not to use this tool and directing to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the cyclic behavior and schedule structure, but does not disclose side effects, creation vs. modification, or what happens with invalid input. The transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear headline, usage examples, and an Args section. It is not overly verbose; the examples are helpful. Could be slightly more concise by omitting some redundancy, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema shown and no description of return value, the description is incomplete. It also does not relate to other generator tools among the many siblings. For a simple add tool, the missing return info is a notable gap, but the core functionality is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds detailed semantics: name with examples, schedule with explanation and example dictionary format, batch_size with default and meaning (tokens per arrival). It compensates well, though the schedule type remains somewhat vague due to 'additionalProperties: true' in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a NonStationaryGenerator with arrival rate changing over cyclic time windows, distinguishing it from the stationary add_generator among siblings. The verb 'Add' and the resource 'NonStationaryGenerator' are explicitly connected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (morning rush, factory shifts, call center) and explains the cyclic repetition. However, it does not explicitly state when NOT to use this tool or mention the alternative stationary generator, though the examples imply when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the key behavioral trait: 'Every item is processed at every station (no bypass option).' It does not mention authorization, rate limits, or side effects, but the core behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: a short main sentence, a behavioral note, an alternative tool reference, and a clear bulleted Args list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (adding a pattern with stations) and that output schema exists but is not described, the description covers the main use. However, it does not fully specify all possible station properties (only shows example with name, time, distribution), leaving some ambiguity about additional properties.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section adds meaning: explains 'name' with examples, 'stations' with a sample list of objects showing expected structure (name, time, distribution), and 'transport_time' with its function. This compensates significantly for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a Conveyor pattern with sequential processing stations' with specific verb and resource. It differentiates from sibling 'add_conveyor_line' by noting 'no bypass option' and directing bypass use cases to the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool versus 'add_conveyor_line' (for stations with bypass logic). However, it does not provide other when-to-use or when-not-to-use guidance beyond that single alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the bypass logic (if free process, if busy bypass), return loop, and processed items exit. It adequately reveals behavioral traits beyond just 'add'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a bold purpose statement, a 'How it works' section, and a bulleted argument list. It is front-loaded with key info, though could be slightly more concise by removing the 'This is the preferred tool' repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, output schema) and many siblings, the description explains the behavioral logic and parameter meanings. It doesn't mention prerequisites like needing a network, but for a creation tool it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides brief one-line explanations for each parameter (e.g., 'Mean processing time'), but lacks depth like allowed values or dependencies. Adds meaning but minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a complete conveyor line with Try-or-Bypass workstations. It distinguishes from siblings like add_conveyor (likely simpler) and add_conveyor_workstation (individual) by emphasizing it creates everything in one call and is preferred for bypass logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'THIS IS THE PREFERRED TOOL for conveyor systems with bypass logic,' providing clear context for when to use it. However, it does not mention when not to use it or compare to alternatives like add_conveyor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: token conservation, counter monotonicity, and the circulation structure. It explains the closed network behavior and state variables, though it could mention that the tool adds a subnetwork to the model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a diagram, bullet points, and clear sections. It front-loads the core concept and uses every sentence informatively, though slightly longer than necessary for simple tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, closed network), the description covers the model structure, token conservation, and use cases. It does not detail all distribution options but output schema exists, reducing the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions n_customers, channels, thinking_time, and service_time implicitly through the model context, but does not explicitly describe standard_deviation, deviation_unit, time_unit, or distribution parameter meanings. With 0% schema coverage, the description partially compensates but omits some parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds a finite population (closed) queueing network with N entities recirculating through c servers. It provides a structure diagram and specific use cases, distinguishing it from sibling queue types like balking, reneging, or bounded queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists multiple use cases (manufacturing, repair, taxi fleet, call centre agents, Engset model) and mentions behavior when thinking_time=0, but does not explicitly contrast with other queue types or specify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral load. It explains the two-unit knob system, auto_connect behavior, and distribution options. However, it lacks details on idempotency, side effects, or preconditions (e.g., whether a machine with the same name can exist). The coverage is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a usage note, a units explanation, and a detailed arg list. It is concise yet thorough, with every sentence adding value. The front-loading of key information aids quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (8 parameters, no annotations, output schema exists), the description covers all parameters and key behaviors. It lacks some higher-level context (e.g., how the machine integrates into the network), but the output schema mitigates the need for return value documentation. Overall, it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no property descriptions), so the description fully compensates. For each parameter, it adds meaningful context: for auto_connect, it explains when to set False; for deviation_unit, it explains inheritance; for distribution, it lists valid values. This goes well beyond the schema's type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a Machine (Server) pattern with multiple processing channels', specifying a concrete verb ('Add'), a resource ('Machine pattern'), and a distinguishing feature ('multiple processing channels'). This helps differentiate from sibling tools like add_blocking_machine or add_preemptive_machine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general usage context ('Use this for processing stations like machines, servers, workstations') and a specific note about auto_connect for parallel machines, but it does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that only specified elements change and others keep positions, and includes an example. However, it does not mention constraints (e.g., coordinate bounds), idempotency, reversibility, or authorization requirements. For a mutation tool with no annotations, more behavioral context is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a direct statement of purpose, usage context, a brief workflow, and a parameter breakdown with example. Every sentence adds value without unnecessary verbosity. It is concise but not terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an output schema (not shown), the description covers purpose, usage, and parameters well. It does not describe return values, but the presence of an output schema likely covers that. The workflow context and parameter explanation make it reasonably complete. A slight gap is the lack of behavioral constraints like coordinate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (0% coverage) with only a generic object array. The description compensates fully by detailing the required fields (id, x, y) with a concrete example, adding significant meaning beyond the schema. It clearly explains the structure and usage of the 'positions' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear action verb ('Set') and specific resource ('canvas coordinates for places and transitions by ID'). This distinguishes it from sibling tools like 'move_elements_by' (offset-based) and 'auto_layout' (automatic). The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('after adding new elements or to clean up a cluttered layout') and provides a typical two-step workflow involving 'list_elements'. It explains that unlisted elements retain positions, offering clear context. However, it does not explicitly mention when not to use it or alternatives like 'auto_layout'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the constraint (bipartite) and parameter meanings, but lacks details on error conditions (e.g., invalid node types), return value behavior, or side effects. With zero annotations, more behavioral context would be expected for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line title, a usage note, and an Args block. It avoids redundancy and is well structured. However, the Args section could be shortened by relying on schema defaults, but it's still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) and 4 parameters with 0% schema coverage. The description explains parameters but lacks error handling, prerequisites (e.g., network must exist), and return value semantics. Given the simplicity and sibling context, it is moderate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides an Args section explaining source_id, target_id, weight, and arc_type with meanings. Although the arc_type values are indirectly given ('normal', 'inhibitor', 'read'), the descriptions are helpful. Could be improved with constraints (e.g., weight > 0).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add an arc connecting a place to a transition or vice versa', specifying the verb, resource, and the bipartite constraint. It distinguishes itself from sibling tools that add other Petri net elements, and explicitly marks itself as a low-level tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'LOW-LEVEL TOOL — use only when no existing pattern covers the required topology', providing clear when-to-use guidance. It also mentions the bipartite constraint, indicating when not to use (invalid connections).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: creates input places, transition fires when all slots have tokens, requires external wiring via connect_patterns, and returns slot place_ids. It covers creation and wiring requirements well, though does not discuss auth or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably sized and front-loaded with purpose. It includes examples and details, though there is slight redundancy in explaining weighted inputs. Overall, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no schema coverage, but an output schema exists, the description covers all parameters, use case, wiring, and return behavior. It lacks some specifics on output format but is sufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining each parameter in the Args section, including examples for weighted inputs, defaults, and time units. It adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds an Assembly (Join) pattern that synchronizes multiple flows into one, distinguishing it from siblings like add_fork_join or add_merge. It provides specific verb and resource, and includes examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for synchronizing flows but lacks explicit guidance on when to use versus alternatives (e.g., add_fork_join, add_merge). No when-not-to-use or alternative comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It describes the logic (primary transition fires first if resources) and the meaning of parameters, but lacks details on side effects, permissions, or limitations. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at around 10 lines, starting with a clear purpose then an overview and a parameter list. Front-loaded and efficient, though the parameter descriptions could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (1 required), no schema descriptions, and an output schema (so return values are covered externally), the description adequately explains the tool's purpose, behavior, and all parameters. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides detailed explanations for all 7 parameters, including the format for resource_place_ids and the time_unit options, adding significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a 'PriorityChoice pattern for resource-dependent branching' with a specific logic ('do X if resources available, otherwise do Y'). This distinguishes it from sibling tools that add other patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (resource-dependent branching) and describes the behavior, but it does not explicitly list when not to use it or name specific alternatives, though the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the branching behavior and priority rule clearly, but does not mention any side effects or restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with examples, but slightly verbose; could be more concise without losing key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential input parameters and behavior, but returns value is not described and output schema is not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates with explanations, examples for routes, and clarification of the priority rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a Router pattern that branches flow into multiple paths, using a specific verb and resource. It distinguishes from sibling tools that add other components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed usage instructions for the routes parameter with examples, but does not explicitly state when to use this tool versus similar branching tools like add_priority_choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It states it exports the current net and returns a string, implying no side effects. However, it does not explicitly confirm read-only nature or discuss performance/limits. The compatibility note adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. No redundant or filler content. Every sentence adds value: purpose, output type, and compatibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with no parameters and an output schema, the description covers input (current net), output (string), and compatibility. It does not explain 'current Petri Net' context, but that is likely assumed. Sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the description adds no parameter-level details. Per guidelines, 0 params gets baseline 4, and the description is clear about output format, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export the current Petri Net to PNML XML format' with a specific verb ('Export') and resource ('PNML XML'). It distinguishes from siblings (many add_* and connect_* tools) by being the only export operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions compatibility with TINA, PetriObjModel, and CPN Tools, but does not explicitly state when to use this tool vs alternatives or any prerequisites. No exclusions or usage contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destructive nature (modify), partial update, and prerequisite discovery. However, it lacks details on error handling, permissions, or reversibility, which are relevant for a modify operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences plus a bullet list for arguments. It is front-loaded with the core purpose and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (which exempts description from explaining return values), the description is sufficiently complete. It covers usage, parameters, and prerequisites. The only minor gap is not mentioning the output shape, but that is optional under the rule.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining each parameter's purpose, providing an example for place_id, and clarifying that omitted fields remain unchanged. This compensates well for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Modify' and the resource 'existing place in the Petri net', distinguishing it from sibling tools like 'modify_arc' and 'modify_transition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions partial update behavior ('Only provided fields are updated') and a prerequisite step ('Use list_elements or get_network_status to discover place IDs first'). While it doesn't explicitly state when not to use, this guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the specific checks performed, but does not mention what happens on failure (e.g., error or return value) or any side effects. Since there are no annotations, more detail on output behavior would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences—with the main action in the first sentence and supporting details in subsequent ones. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no annotations, the description covers the main purpose, checks, and usage context. It could mention the output (e.g., validation report), but an output schema exists to provide that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description adds no parameter information, but none is needed. It compensates by explaining the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: validating a Petri net topology. It lists specific checks (bipartite constraint, dangling transitions, duplicate IDs) and distinguishes it from sibling tools that are primarily for adding elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool: after building a custom topology with add_place, add_transition, add_arc, before export. It provides clear context, though no explicit when-not cases are needed for a validation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively carries the burden. It discloses key behaviors: the gate allows flow only when signal is present, signal is read but not consumed (information link), and initial_signal controls initial state. It does not discuss side effects or safety, but the 'add' action implies creation, and output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating purpose, then one line about signal behavior, then two bullet points for parameters. Every sentence is necessary and front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, output schema present), the description covers all essential aspects: purpose, signal behavior, parameter meanings. It is self-contained and sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), so the description must add meaning. It provides clear explanations: 'name' with example values, 'initial_signal' with behavioral implication (starts enabled if True). This adds value beyond the basic schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a Controller (Gate) pattern that controls flow based on a signal. It uses specific verb 'Add' and resource 'Controller (Gate)', distinguishing it from other 'add_*' tools that add different elements like machines or queues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides behavioral context (signal is read but not consumed) but lacks explicit guidance on when to use this tool versus alternatives like 'add_wip_controller' or 'add_threshold_activation'. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions 'Try-or-Bypass logic' but does not explain it, nor does it describe side effects, safety, or requirements beyond parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose, usage guidance, and parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and an output schema, the description covers all parameters and gives a basic behavioral hint. It could elaborate on 'Try-or-Bypass logic' but is otherwise complete given the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates with detailed parameter descriptions in the Args section, providing meaning for each parameter including example values and units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a SINGLE ConveyorWorkstation with Try-or-Bypass logic', which is a specific verb and resource. It also distinguishes from the sibling add_conveyor_line by noting the single vs multiple workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For multiple workstations in a chain, prefer add_conveyor_line instead', providing clear when-to-use and when-not-to-use guidance with an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool's behavior in terms of token creation and interval semantics, but does not disclose potential side effects, destructive actions, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, examples, and canonical translations. While somewhat verbose, the examples enhance clarity and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 1 required, no annotations, and with an output schema present, the description comprehensively covers all parameters and usage contexts. It provides enough information for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, yet the description thoroughly explains each parameter, including examples for interval, rate, distribution, standard_deviation, batch_size, time_unit, and deviation_unit. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a Generator pattern that creates tokens at regular intervals. It explains the tool's purpose with specific verb and resource, and the sibling tools list includes add_nonstationary_generator, indicating differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this for arrival processes' and provides detailed guidance on when to use interval vs rate, distribution selection, and batch_size. However, it does not directly mention alternative tools for non-stationary arrivals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the core behavior: entity tries resources in order, each with its own parameters. However, it omits what happens when all resources are busy (e.g., blocking, waiting). Still, the provided behavioral model is clear and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a high-level summary, a behavioral model, then a clear Args list with examples. Every sentence adds value, and the most important information is front-loaded. It is not verbose and uses appropriate formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, role in simulation), the description covers the configuration well. It explains the preference ordering and parameter duties. However, it lacks information on how the ResourceSet interacts with other model elements and what happens under resource exhaustion. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so thoroughly: each parameter is explained with types, defaults, and examples, especially the 'resources' array with a nested dict structure. This adds immense value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a ResourceSet that models entity trying resources in preference order. The verb 'add' and the noun 'ResourceSet' are specific, and the description distinguishes it from siblings like add_machine by explaining the preference-based resource selection logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (for resource preference ordering) but does not explicitly state when not to use it or how it compares to similar tools like add_multi_resource. There is no guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral context. It describes the arc addition and naming lookup, but does not mention potential side effects (e.g., errors if names don't exist), permissions, or atomicity. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear single-sentence summary followed by a structured 'Args' block. Every sentence adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description explains the core logic and parameters well. However, it omits prerequisites (e.g., the queue and consumer must already exist) and does not mention the output, though an output schema exists. Slightly incomplete for a fully self-contained definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's 'Args' section provides explicit meanings for both parameters: 'queue_name' is linked to add_bounded_queue, and 'consumer_name' identifies the downstream consumer type. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Wire capacity recycling' and the resource 'BoundedQueue and its consumer'. It specifies the exact action (adding an arc) and distinguishes itself from siblings like connect_blocking_consumer by focusing on bounded queue capacity recycling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's function and the naming conventions, allowing an agent to infer when to use it (when a bounded queue and consumer need capacity recycling). However, it does not explicitly state when not to use it or list alternative tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: tokens are NOT consumed, an extra output arc is added, and the entity continues to flow. It could mention potential side effects like duplicate calls, but the given information is adequate for a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for action, behavior, and parameters. Every sentence adds value, and it avoids redundancy. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (though not provided in the input), the description covers the essential aspects: purpose, parameter meanings, and execution order. It could include error handling or idempotency, but it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates well. It explains 'wip_controller_name' as the instance name passed to 'add_wip_controller', and 'exit_place_id' as the output place ID of the last pattern. This adds meaningful context beyond the schema's simple type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wire the WIP return arc') and the resource/context ('recycle a WIP slot when an entity reaches the exit place'). It distinguishes from sibling tools like 'connect_return_loop' and 'connect_blocking_consumer' by specifying the exact behavior of adding an output arc to the controller's WIPSlots place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('Call AFTER wiring the WIP-controlled section, so the producer transitions of exit_place_id exist'), providing clear ordering context. It does not explicitly list when not to use, but the context is sufficient for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it is a read operation ('Get') and details the return content. With no annotations, this provides adequate transparency about its non-destructive nature and basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that directly convey the tool's purpose and return value. No superfluous information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently covers what the agent needs to know: it returns a summary of places, transitions, arcs, and validation status. This is complete for a simple status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description has no burden to add parameter meaning. According to the baseline rule for zero parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the current status of the Petri Net and lists the key components included (places, transitions, arcs, validation status). This distinguishes it from sibling tools that focus on specific aspects like validation or simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like validate_net or get_network_bounds. However, the description implies it is for a general overview, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's creation nature and layout requirement but does not mention side effects, permissions, or confirmation of success. While adequate, it could be more explicit about the operation's safety or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief purpose statement, a usage guideline, a layout prerequisite, and a clear parameter list. It is appropriately detailed for 9 parameters but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations), the description covers purpose, usage, parameter semantics, and prerequisite layout calls. It does not explain return values, but an output schema is present, so it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates fully by explaining each parameter's meaning and allowed values (e.g., distribution options, probability range, time_unit units). This adds significant value beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a single transition') and the resource ('to the Petri net'). It distinguishes itself from sibling tools by explicitly labeling itself as a low-level tool for use when high-level patterns do not apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'use only when no existing pattern covers the required topology' and 'for standard constructs, prefer high-level pattern tools.' It also prescribes a prerequisite step ('ALWAYS call find_free_position...') which aids correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the behavior (capacity slot returned upon downstream processing) and the ordering requirement. However, it lacks details on side effects, error conditions, or required permissions. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: 4 sentences total, including the Args block. The main purpose is front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description doesn't need to explain returns. It covers the core action, parameter semantics, and usage timing. For a connector tool with two simple string params, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully explains both parameters: blocking_machine_name ('Instance name passed to add_blocking_machine') and downstream_name ('Instance name of the downstream consumer'). This adds critical context beyond the schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: wire capacity recycling between a BlockingMachine and its downstream consumer. It explains the mechanism (returning a capacity slot) and specifically references BlockingMachine, distinguishing it from other connect_ tools like connect_bounded_consumer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage instruction: 'Call this AFTER connecting BlockingMachine output to downstream input.' This helps the agent order operations. However, it does not explicitly state when not to use this tool or compare to alternatives, though the context hints at its specific role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the critical destructive behavior 'clearing any previous network,' which is a key safety detail. This adds value beyond a simple 'create' by warning of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus an Args line. It front-loads the core action and clearing behavior, with no superfluous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, absence of annotations, and presence of an output schema, the description is quite complete. It covers the tool's purpose, behavior (clearing), and parameter. It could mention the return value or the exact scope of 'clearing,' but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the 'name' parameter's purpose: 'Name for the new network (default: "PetriNet")'. This adds meaningful context beyond the schema's type and default, compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new empty Petri Net, clearing any previous network.' It uses a specific verb ('create') and resource ('Petri Net'), and distinguishes from sibling tools which add components to an existing network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this FIRST when building a new model from scratch,' providing clear context for when to invoke the tool. However, it lacks explicit when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions overlap avoidance but does not specify what happens if no free position is found near the given element (e.g., congested area). This lack of failure case disclosure limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, usage guidelines, and parameter explanations. It is front-loaded with the main purpose and every sentence adds value. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for guiding usage, including parameters and workflow. However, it does not explicitly state that the tool returns x and y coordinates (though implied by 'pass those coordinates directly'). The return format is assumed from context. Slight gap for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context: near_element_id is explained as an ID from list_elements, and direction lists the options ('above', 'below', 'left', 'right') with relative positioning. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds canvas coordinates for a new element near an existing one, avoiding overlaps. It uses a specific verb 'find' and resource 'canvas coordinates', effectively distinguishing it from sibling tools like add_place and add_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this BEFORE add_place or add_transition' and provides a recommended workflow with numbered steps. It gives clear context on when to use the tool and how to pass the returned coordinates to subsequent tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the return fields in detail and implies a read-only operation. It does not mention any side effects or performance concerns, which is acceptable for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-sentence purpose, a brief usage note, and a bulleted list of return fields. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (no parameters, clear output), the description is complete enough. It explains purpose, usage context, and all return fields. Minor omission: no mention of coordinate units or whether all elements are included, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is effectively 100%. The description adds no parameter info, which is appropriate. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the spatial bounding box of all elements in the net' with a specific verb and resource. It distinguishes itself from siblings like 'find_free_position' and 'auto_layout' by focusing on the overall extent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use to understand the current layout extent before adding new elements or deciding where to place a new pattern relative to existing ones,' giving clear context for when to use. It does not explicitly state when not to use or list alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It warns 'WARNING: Destructive — the place and ALL arcs connected to it are deleted,' clearly disclosing the cascading deletion behavior. This adds value beyond the tool name, though additional details about network invariants or constraints would improve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for the action, a clear warning, and an args section. Every piece of information is essential, and the structure is front-loaded with the main purpose, leaving no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, destructive operation), the description covers the main functionality and parameter. An output schema exists, so return values are handled elsewhere. It lacks details about post-removal network state, but is largely complete for a basic deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes 'Args: place_id: ID of the place to remove,' which clarifies the parameter's role. Despite 0% schema coverage, this compensates by explaining what the ID refers to. More specifics (e.g., format) could be useful, but it's adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a place and all its connected arcs from the Petri net.' This specifies the verb (remove), resource (place), and scope (including all connected arcs), effectively distinguishing it from sibling tools like remove_arc and remove_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool deletes a place and its arcs, implying its use when complete removal of a place is intended. While it does not explicitly mention alternatives or when not to use it, the warning and sibling list help an agent infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Clearly describes that one arriving token produces one token in each output place simultaneously. Could mention if it mutates existing network, but behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with two introductory sentences, bulleted examples, and clear Args list. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), description doesn't mention return value. However, for an add operation, output is likely a success indicator; the description is otherwise complete for understanding and using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds detailed Args section explaining 'name' as broadcast point name and 'outputs' as branch names with examples, providing meaning beyond schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Add' and resource 'Duplicate (Broadcast) pattern', clearly stating it copies one token into N independent copies. Differentiates from siblings like add_merge or add_unbatch by explaining the broadcast behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: parallel processing of the same item by independent services, with concrete examples. Does not state when not to use, but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool modifies arcs, describes partial update behavior, and lists possible arc types. It does not cover destructive implications or permissions, but it is fairly transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage note, then parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters with partial updates) and the presence of an output schema (not shown but indicated), the description is complete. It covers what the tool does, how to use it, and parameter details, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It explains each parameter: arc_id is required for identification, weight and arc_type are optional with explicit examples ('normal', 'inhibitor', 'read'). It adds meaning beyond the schema, such as the partial update behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify an existing arc in the Petri net,' using a specific verb and resource. It distinguishes itself from siblings like 'add_arc' and 'remove_arc'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Only provided fields are updated — omitted fields stay unchanged. Use list_elements to discover arc IDs first.' It explains partial update behavior and suggests a prerequisite for finding arc IDs, though it doesn't explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses partial update behavior and parameter effects (e.g., priority 'fires first in conflict', probability range). It does not cover error conditions or side effects, but it addresses the main behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the action, a key note, a useful prerequisite, then a clear parameter list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 8 parameters and provides helpful context (e.g., priority semantics). It does not explicitly require that the transition exists or explain error handling, but given the output schema exists, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining each parameter's purpose, allowed values (e.g., distribution types), and default behavior ('omit to keep current'). This is highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify an existing transition in the Petri net,' using a specific verb and resource. It explicitly distinguishes from sibling tools like 'add_transition' and 'remove_transition' by focusing on modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Only provided fields are updated — omitted fields stay unchanged.' It advises to 'Use list_elements or get_network_status to discover transition IDs first,' establishing a prerequisite. However, it does not explicitly discuss when not to use this tool or contrast with other modify tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the operation (shift by dx/dy) and parameter directions, but does not disclose return value details, side effects, or whether the action is reversible. With no annotations, the description carries full burden and falls short on behavioral completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with purpose, followed by structured argument explanation. Every sentence adds value without redundancy. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description covers input parameters well. Lacks mention of limitations (e.g., invalid IDs, connected elements) but is otherwise adequate for a straightforward move operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully with a clear argument block explaining each parameter's meaning, units, and direction (positive = right/down). Adds significant value beyond the schema's bare type and title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool shifts elements by a relative offset. Distinguishes from siblings like 'set_positions' (absolute) and 'find_elements' (search) by noting it avoids needing to query coordinates first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives usage context: use when user says 'move generator 200px right' without needing coordinates. Also provides guidance to call 'find_elements' first for pattern moves. Covers prerequisites and typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains the split-join behavior, synchronization requirement, and return value (branch IDs). Could mention error conditions or prerequisites, but sufficient for a pattern addition tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, differentiation, and Args. Front-loaded with key behavior. Slightly long but every sentence adds value; minor room for trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 input parameters, documented behavior, and output description (branch IDs for wiring), the description covers essential aspects. Lacks mention of interactions with running networks, but adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Add section thoroughly documents each parameter: meaning, default, constraints (e.g., branch_times length equals n_branches), and valid values for distributions and time units. Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it adds a ForkJoin pattern for parallel branch execution, with specific verb and resource. Differentiates from assembly and duplicate siblings, establishing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Essential for modeling parallel workflows that must synchronize before proceeding.' Also contrasts with assembly and duplicate to guide when not to use those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the auto-cursor behavior and the need for explicit coordinates, stating that without them the element collides on follow-up edits. This adds significant behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, usage guidance, layout procedure, and parameter list. It is concise but not overly short; each section adds value. Minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters and no schema descriptions, the description covers parameter meanings and usage context thoroughly. It references the essential companion tool (find_free_position). However, it does not mention error conditions or what the output schema contains (though output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section provides clear meaning for all five parameters, e.g., 'tokens: Initial token count (marking)', 'x: Canvas X coordinate — obtain from find_free_position'. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a single place (position) to the Petri net.' It distinguishes itself from many sibling tools by explicitly noting it is a low-level tool for when high-level patterns don't cover the topology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use only when no high-level pattern covers the required topology, and ALWAYS call find_free_position first. It also lists alternatives (e.g., add_generator, add_machine) and gives a step-by-step procedure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: blocking (not rejection) when limit reached, the need for a return loop via connect_wip_return, and the fact that entities continue to flow after recycling a slot. This meets the high burden of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (definition, structure, use cases) and front-loaded with the core purpose. It is slightly verbose but every sentence contributes value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two parameters, existence of an output schema, and the tool's moderate complexity (WIP limiting with return loop), the description covers all essential aspects: purpose, behavior, structure, integration with other tools, and use cases. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'wip_limit' controls the maximum simultaneous entities, adding context beyond the schema's default and type. The 'name' parameter is implied from the function name but not explicitly described. Since schema coverage is 0%, the description adds meaningful clarification for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool as a 'WIP (Work In Progress) limiter — Kanban / CONWIP entry gate', specifying it limits entities to a given limit via an entry gate. This distinguishes it from sibling tools like add_controller or add_buffer, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases (CONWIP production lines, Kanban pull, pipeline stages, thread pool) and advises to call 'connect_wip_return' after wiring. While it lacks explicit 'when not to use' guidance, the use cases and structural explanation effectively guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the algorithmic behavior: topological layering, successor inheritance, symmetrical distribution. However, it does not explicitly state whether existing positions are overwritten or mention any side effects, so slightly less than perfect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet informative: first sentence states action, followed by algorithmic details, usage context, and a clear parameter list. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters and an output schema (not shown but existence noted). The description explains the algorithm and when to call it, which is sufficient for this layout tool. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed explanations for all four parameters, including defaults and units (canvas units, coordinates). This adds significant value beyond the schema's bare defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to re-layout the entire net using topological left-to-right layering. It explains the algorithm and distinguishes itself from sibling tools, which are all element addition/connection tools, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this after building the complete net when the automatic cursor placement produced a cluttered or overlapping layout,' providing clear when-to-use guidance. No explicit when-not or alternatives are given, but siblings are unrelated, so it's acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return statistics (final markings, mean values, min/max, Terminators block) and parameter constraints (time unit matching delays). It does not mention potential side effects, but simulation is likely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, a paragraph of details, and an Args block. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (even if not detailed here), the description sufficiently explains the return values. The two parameters are fully explained, and the tool's role in the workflow (simulating after building) is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), but the description adds detailed meaning: simulation_time must match transition delays, time_unit has explicit options and default, and the response echoes duration for verification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a discrete-event simulation of a Petri Net and returns statistics. It uses specific verb+resource and distinguishes from sibling configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly say when not to use, it implies usage after building the net. The context of sibling tools (all configuration except get_*) makes it clear this is the execution tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the complete cycle (Queue+Free -> Grab -> Move -> Release -> Return -> Free) and describes all parameters, leaving no ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for intro, examples, cycle, and args. It is front-loaded with purpose. However, it could be slightly more concise as some explanations are repeated across parameter lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (12 params, 1 required) and presence of an output schema, the description covers purpose, usage, parameter semantics, and behavioral cycle. It provides enough context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides detailed explanations for all 12 parameters, including units and distributions. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a TransportAgent (cyclic resource) pattern, lists examples like robots and forklifts, and explains the cycle. This effectively distinguishes it from sibling tools like add_machine or add_conveyor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for cyclic resource patterns), but does not explicitly state when not to use it or name alternatives. The examples and cycle description implicitly guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns detailed info for every element. No side effects or permissions needed; lacks mention of potential performance or pagination but sufficient for read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return details are covered. Description complements siblings and usage context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline score of 4. No additional info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all places, transitions, and arcs, distinguishing it from modify/remove/add siblings. Purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this before modify/remove operations', providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently explains the tool removes redundant elements while preserving semantics, markings, and timing. Minor omission: doesn't mention if the operation is reversible or idempotent, but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: verb+resource, usage timing, and detailed behavior. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with output schema, the description is complete. It states purpose, timing, and effects. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; baseline is 4. Description adds context about what the optimization achieves, which is extra value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool optimizes a Petri Net by removing redundant elements, specifically intermediate Transfer transitions, and simplifying topology. It distinguishes itself from sibling tools that add elements or configure networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call the tool: 'AFTER the network is fully built, BEFORE exporting.' This provides clear usage timing and differentiates from other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals important behaviors: creates one input place per stream with naming convention, and instructs to wire via connect_patterns. Could add more about side effects like place creation, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences plus a bulleted use-case list and parameter descriptions. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for an add tool: explains creation of places, wiring, and gives examples. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are explained with examples (name as 'OrderMerge', inputs as array of stream names). Schema has no descriptions, so the tool description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a merge pattern (OR-join) that combines multiple streams into one output, with a specific verb and resource. It distinguishes from assembly by noting it fires on ANY input, not ALL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: orders from multiple sources to one queue, parts from parallel machines. Also contrasts with assembly tool, giving clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the behavioral effect: adds a READ arc, blocks machine during off-periods, items wait in queue, processing resumes when active window starts. While comprehensive, it doesn't explicitly mention side effects or prerequisites beyond the calling order, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a concise explanation of the mechanism and clear ordering instructions. Each sentence adds value, and the Args section is well-structured. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 simple parameters, clear prerequisites), the description fully covers what the agent needs: what it does, how it works, and when to call it. The output schema exists (though not shown), so return values are covered. Complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The Args section explains each parameter: schedule_name is the name from add_scheduled_availability, machine_name from add_machine or add_breakdown. This adds essential context beyond the schema's minimal definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gate a machine with a shift schedule via READ arc.' It specifies the type of arc, the effect on the machine, and how it controls flow during off-periods. This differentiates it from sibling tools like 'add_arc' or 'connect_blocking_consumer' by being specific to schedule-based gating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states ordering: 'Call AFTER both add_scheduled_availability and add_machine / add_breakdown.' It also clarifies the use case (to enable schedule-based blocking) and implicitly when not to use it (if not using schedule gating). This provides clear guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description covers search semantics (case-insensitive substring, empty string returns all) and implies read-only operation. However, it doesn't explicitly state safety or side effects, which would be ideal for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized, front-loads the purpose, follows with usage guidance and a detailed workflow example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately avoids explaining return values. It covers search behavior, parameter details, and a clear workflow, making it complete for a search tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: name_pattern (case-insensitive substring, empty returns all) and element_type (options: place, transition, null for both). This adds critical semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Search places and transitions by name substring.' It specifies the verb (search) and resource (places/transitions), and the scope is clearly distinguished from siblings like list_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this to locate element IDs before calling find_free_position, set_positions, or move_elements_by.' Also notes it's faster than list_elements for specific patterns and gives a typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: seizes one token from each pool simultaneously, releases upon completion. All parameters are explained in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient structure: definition, behavior, use cases, parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema coverage and no output schema dependence, description fully covers all six parameters, behavior, and use cases. Complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds detailed explanations for every parameter, including examples and defaults, far exceeding schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add a MultiResource (AND-Resource) pattern — op requiring multiple simultaneous resources.' It distinguishes from Machine, providing a specific verb-resource pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (Painting, Surgery, Welding) and contrasts with Machine, providing clear guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pns-server MCP server](https://glama.ai/mcp/servers/petri-net-sim/pns-server/badges/card.svg)](https://glama.ai/mcp/servers/petri-net-sim/pns-server)

Score Badge

Copy to your README.md:

[![pns-server MCP server](https://glama.ai/mcp/servers/petri-net-sim/pns-server/badges/score.svg)](https://glama.ai/mcp/servers/petri-net-sim/pns-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/petri-net-sim/pns-server'

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