pm4py-mcp

by azizketata

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, targeting different artifacts (logs, models, graphs, abstractions) and actions (discover, visualize, filter, abstract). Even similar tools like abstract_dfg vs discover_dfg+visualize_dfg are clearly separated by output type (text vs graph). Overlap is minimal and well-documented.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., discover_petri_net, abstract_log_features, filter_variants). There is no mixing of camelCase or other conventions, and the verbs are semantically grouped by function (discover_, abstract_, filter_, etc.).
Tool Count2/5
With 67 tools, the server is far above the typical 3-15 range. While the domain (process mining) is broad, many tools could be consolidated (e.g., multiple social network discovery tools into one with a parameter). This large surface likely overwhelms LLM agents and increases selection errors.
Completeness5/5
The tool set covers the full lifecycle of process mining: loading, describing, filtering, discovering (many model types), visualizing, abstracting, conformance checking, simulation, model conversion, and export. There are no significant gaps for the intended analytical workflow.
Average 3.8/5 across 67 of 67 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions output formats (PNG, SVG) but omits behavioral traits such as whether the tool is read-only, authentication needs, or potential side effects like file generation. For a rendering tool, this is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the extreme cost of completeness. While front-loaded, it lacks essential detail and every word could be expanded. It earns its place but fails to provide sufficient 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?
The tool has one parameter with no schema description, no output schema, and no annotations. The description fails to explain prerequisites, return format, or error conditions. For a tool that requires a dfg_id from a prior discovery step, this is critically 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 input schema has 0% description coverage for its single required parameter (dfg_id). The description does not explain what dfg_id represents, how to obtain it (e.g., from discover_dfg), or any constraints. The description adds no value beyond the schema field name.
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 'Render a directly-follows graph (from discover_dfg) as PNG + SVG', specifying the verb 'render', the resource 'directly-follows graph', and the output formats. It distinguishes from sibling visualization tools like visualize_petri_net or visualize_dotted_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, nor does it mention prerequisites like first running discover_dfg. There is no exclusion criteria or context on appropriate use cases.
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 burden of behavioral transparency. It discloses that the output is truncated at max_len characters, but does not mention if the tool is read-only, safe, or has any side effects. Minimal behavioral info.
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 short and front-loaded with the purpose. However, it includes an implementation detail (wraps a specific function) that may be unnecessary for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as indicated by context) and only two parameters, the description adequately covers the output as a textual description and the truncation behavior. However, it lacks information on error handling or prerequisites for log_id.
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 schema has 0% description coverage, leaving the description to explain parameters. It only relates max_len to truncation but does not explain log_id (e.g., what a valid log_id is, where to obtain it). Limited parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it produces a textual description of log-level features including activity set, concurrency, and timing. This clearly indicates the tool's purpose and resource, but it does not explicitly differentiate from siblings like abstract_log_attributes or abstract_variants.
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 abstract_log_attributes or abstract_variants. The description lacks 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 carries full burden. It states the tool is a wrapper and returns a handle with counts, but does not disclose if it is read-only, any side effects, or required permissions. Critical behavioral traits are missing.
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: two sentences that efficiently convey purpose, method, and output. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 2 parameters, the description covers the core purpose and output format. However, it lacks important context like the need for a pre-loaded log (via log_id) and does not explain the BPMN conversion step. Some gaps remain.
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%, so the description must compensate by explaining parameters. It does not mention log_id or noise_threshold, nor how they relate to the Inductive Miner. The description adds no meaningful parameter information beyond the schema's basic types.
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 discovers a BPMN diagram using the Inductive Miner, with a specific verb and resource. It mentions it's a convenience wrapper, which hints at differentiation from sibling discovery tools, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides little guidance on when to use this tool versus alternatives like discover_process_tree or discover_petri_net. It implies usage for BPMN diagram creation but lacks explicit context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the edge semantics but does not state that the tool is read-only, what output is returned, or any side effects. Minimal 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 sentences, no redundant information. Efficiently defines the concept and the edge meaning without fluff.
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?
With three parameters and no parameter descriptions, the tool is incomplete for an agent to use correctly. The output schema exists but is not described. Lack of usage guidance also harms completeness.
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%. The description does not explain any of the three parameters (n, log_id, resource_key). The mention of n in the edge definition is implicit, not as a 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 verb 'discover' specifies the action, and 'subcontracting_network' is the resource. The edge definition clearly explains what A → B means (handoff within n events), differentiating it from sibling network discovery tools like discover_handover_network.
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 that this is for patterns of brief handoffs, nor does it contrast with other network discovery 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?
With no annotations provided, the description carries full burden. It states the output is a textual description and wraps a specific function, but does not disclose behavioral traits such as whether it is read-only, performance implications, error conditions, or effect on system state. The existence of an output schema is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no filler. Every sentence adds value: the first defines core functionality, the second hints at usage context and implementation. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema that is not described, the description lacks completeness. It explains the core purpose and output nature, but misses parameter semantics, usage examples, and behavioral details. For a tool that helps understand slicing dimensions, more context would be beneficial.
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?
Input schema has 0% description coverage (no descriptions in schema properties). The description does not explain the purpose or allowed values of 'log_id' or 'max_len', failing to add any meaning beyond the schema. This is a critical gap for a 2-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a textual description of attribute distributions including value frequencies and quantiles. The verb 'describes' and resource 'attribute distributions' are specific. It distinguishes itself from sibling tools like abstract_variants or abstract_dfg by focusing on attribute-level summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful for the LLM to understand what slicing dimensions exist in the log,' providing a vague use case. However, it gives no explicit guidance on when to use this tool versus alternative abstract_* tools, nor any when-not-to-use or prerequisite conditions.
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 that the tool returns a handle under the 'sna' kind plus resource/connection counts, and explains the beta parameter's effect on distance decay. However, with no annotations, it fails to mention whether the tool is read-only, any authentication needs, or side effects, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a few sentences to convey purpose, edge definition, and beta functionality. It is front-loaded with the main purpose and structured well. However, there is minor redundancy ('resource A's activity was directly followed by...') that could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains the network concept and beta. However, it does not provide enough context about the required input (log_id) or the optional resource_key, which are critical for correct invocation. The complexity is moderate, so completeness is adequate but not strong.
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 explains the 'beta' parameter well, but does not clarify the 'log_id' (what constitutes a valid log ID) or 'resource_key' (its role and expected values). Since schema coverage is 0%, all parameters rely on the description, which only fully handles one out of three.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Discover the handover-of-work network' and defines the edge semantics and beta parameter, making the purpose clear and specific. However, it does not explicitly differentiate from sibling network tools like discover_subcontracting_network or discover_working_together_network, lacking distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's function but provides no guidance on when to use it versus alternatives. It does not mention prerequisites such as requiring a loaded event log, nor does it suggest contexts where network analysis is appropriate. Minimal usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that a ContextNotFound exception is raised for unregistered names, which is helpful. However, with no annotations, it fails to explicitly state that this is a read-only operation or describe any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Every word contributes to the description. Ideal conciseness for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward retrieval operation, especially given the presence of an output schema. However, it would benefit from explaining what a domain context is and how to use it in conjunction with set_domain_context.
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%, placing the burden on the description. It does not explain the 'name' parameter beyond its default value. An agent must infer that 'name' identifies the domain context to retrieve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('domain context'), making the purpose unambiguous. It distinguishes from sibling tool set_domain_context, but does not explicitly link the two.
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 or when not to use this tool, nor any mention of alternatives. The error condition is noted but does not provide usage context versus 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?
No annotations are provided, so the description carries the full burden. It transparently describes the output format, including the structure of each role and the additional metadata (counts, preview). It implies a non-destructive, read-only operation, which is reasonable. The description provides sufficient behavioral context for an agent to understand what to expect.
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, with a clear front-loaded purpose followed by a bulleted list of output details. It avoids unnecessary words. However, it could be more concise by removing the 'pm4py returns' phrasing, but overall it is well-structured.
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 has 3 parameters with 0% schema coverage and no usage guidance, the description is incomplete. While it extensively covers the output (which is already defined by an output schema), it fails to address parameter semantics and usage context. An agent would lack critical information to 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 does not explain any of the three parameters (log_id, activity_key, resource_key). The description focuses solely on output, offering no insight into how to set or use the parameters. This leaves agents guessing about parameter meaning and 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 that the tool discovers organizational roles, defined as activity-sharing clusters of resources. It details the output structure (List[Role] with activities and originator_importance) and mentions the returned handle 'org_roles' along with counts and a preview of the top 5 roles. This is specific, uses a verb, and distinguishes from other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or compare with similar tools like discover_subcontracting_network or discover_handover_network. The agent is left to infer usage from the tool's purpose.
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 internal behavior: variants are auto-ranked by frequency and truncation is based on max_len, not top_k. With no annotations provided, this adds useful transparency. However, it does not disclose whether the operation is read-only or other side effects like performance impact.
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 brief with two sentences. The first sentence clearly states purpose, and the second adds implementation detail. It is concise without extra fluff, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return format is covered) and three parameters, the description is fairly complete. It explains the main behavior and key parameter nuance. However, it could mention that the output is a ranked list or provide example usage context.
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 meaning for two out of three parameters: it clarifies max_len controls truncation (not top_k) and include_performance toggles per-variant performance. log_id is left implicit. This compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool traces variants with frequencies and optionally per-variant performance. It uses specific verbs ('trace') and resources ('variants'). However, it does not explicitly differentiate from similar sibling tools like get_variants or filter_variants, which also deal with variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions it wraps an internal function but does not provide context about preferred use cases or when to choose it over other variant-related 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 provided, so the description must fully disclose behavior. It mentions pruning weak constraints via parameters but does not address potential side effects, required permissions, computational expense, or data volume impacts. Significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single paragraph that front-loads purpose, explains DECLARE, and describes parameters. It is concise but could benefit from bullet points for readability. No wasted sentences.
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?
Mentions return format (nested dict) and counts, but lacks detailed explanation of the output schema structure. With an output schema present, more guidance on interpreting results would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description adds meaning for min_support_ratio and min_confidence_ratio, explaining they prune constraints with ranges and defaults. However, log_id's purpose is not elaborated beyond 'Log Id' from 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 discovers a DECLARE model from an event log, explains what DECLARE is (declarative constraints), and mentions the nested dict return format. This is specific and distinguishes from sibling discovery tools like discover_dfg or discover_petri_net.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor when not to use it. The description lacks context for selection among sibling tools (e.g., when to choose DECLARE over DFG or Petri nets).
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. It does not mention whether the tool is read-only, destructive, requires authentication, or any side effects. The description focuses on output but omits operational 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 concise with three sentences. It front-loads the main purpose and uses a code block for the parameter. No unnecessary details, though the code block is informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It adequately explains the tool's function and key parameter, but lacks context on input prerequisites or log format requirements.
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 compensates partially by explaining noise_threshold (range [0,1] and pruning purpose). However, log_id is not described, leaving a gap. The added parameter info is useful but incomplete.
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 discovers a log skeleton with six constraint types. It is a specific verb+resource and distinguishes itself from siblings like discover_petri_net or discover_declare by focusing on behavioral constraints per activity pair.
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 it is 'useful as a declarative complement to Petri-net / process-tree discovery,' providing some context but no explicit when-to-use or when-not-to-use guidance. It lacks alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes collaboration semantics but does not disclose safety, authentication, or performance traits; no annotations provided to supplement.
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 action, no redundant content.
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?
Adequate for purpose but lacks parameter details and usage context; output schema present but not described.
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% and description does not explain the parameters (log_id, resource_key) beyond mentioning resources; does not compensate for 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 the tool discovers the working-together network, defines edge meaning, and differentiates from sibling tools by noting independence of order.
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 or not use this tool versus alternatives like discover_handover_network or discover_subcontracting_network.
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 description carries full burden. Only states the filtering logic (keep cases in range). Does not disclose whether the log is modified in-place or returns a new log, any performance implications, or side effects. Minimal behavioral detail beyond 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?
Extremely concise: two sentences, no extraneous words. The main action is front-loaded. Every sentence adds value without repetition.
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 filter tool, the description is adequate in purpose and usage context. However, it lacks parameter descriptions, which is a notable gap. Output schema exists, so return values are not required in description. Missing behavioral transparency and parameter info reduce completeness.
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 coverage is 0%, meaning the description provides no explanation for any of the three parameters (log_id, min_size, max_size). The schema titles are minimal and not informative. The description adds no meaning beyond the schema fields.
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 filters cases based on event count range [min_size, max_size]. Differentiates from sibling filter tools by specifying the filtering criterion (case size). Useful context provided (removing outliers before discovery/conformance).
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 'Useful for removing outlier cases... before discovery/conformance', which gives clear context for when to use. However, it does not explicitly mention when not to use it or name alternative tools, though the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It adds detail about ISO-8601 format and a normalization step due to pm4py parsing, which is helpful. However, it does not explicitly state that the tool is non-destructive (read-only), nor does it describe any side effects 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 concise with three sentences, no superfluous words. However, it could be better structured by listing parameters explicitly or using bullet points. The front-loading is acceptable.
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 has 3 parameters (0% schema coverage), no annotations, and an output schema present, the description is incomplete. It fails to explain the 'ocel_id' parameter and does not mention return values (though output schema may cover it). For a filter tool, more context about the filtering logic and edge cases would be expected.
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 fully document parameters. It explains start and end (ISO-8601 strings and normalization) but completely omits the 'ocel_id' parameter, which is required and its purpose is unclear. This is a significant 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 tool keeps events within a time range using the verb 'keep' and resource 'events'. The name 'filter_ocel_time_range' already indicates it's for OCEL, distinguishing it from sibling 'filter_time_range' for regular logs.
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 filtering object-centric event logs by time, but does not explicitly state when to use this versus alternatives like 'filter_time_range' or 'filter_ocel_attribute'. No exclusions or prerequisites 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?
Discloses that output is capped at 'top_k' (default 20) and includes total variant count for truncation awareness. However, with no annotations provided, it does not cover permissions or side effects, though the 'get' verb implies 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?
Two sentences: the first states the purpose, the second adds a key behavioral detail. No wasted 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?
Given the existence of an output schema, return values need no explanation. However, the description lacks context about required parameter 'log_id' and does not differentiate from sibling variant tools. Adequate for a simple retrieval but with gaps.
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 mentions 'top_k' and its default but does not explain 'log_id' or what constitutes a 'variant'. Parameter meaning is partially provided.
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 specifies 'Return the most-common trace variants and their counts.' The verb and resource are distinct from sibling tools like 'abstract_variants' and 'filter_variants'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'abstract_variants'. The description only mentions output capping but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool returns a reverse-chronological event tail and is a wrapper, but omits details like authorization, side effects, or rate limits. The output schema may cover return structure, but behavioral traits remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, using only two sentences. However, it sacrifices parameter explanations for brevity, making it less effective.
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 output schema exists (not shown), the description clarifies the core purpose but lacks parameter details and usage context. For a simple 'tail' tool, it is nearly adequate, but the missing parameter semantics leave gaps.
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 coverage is 0%, so the description should explain parameters. It does not mention log_id or max_len, leaving their semantics and impact ambiguous. The default for max_len hints at tail length, but no explicit guidance is provided.
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 returns a tail of events in reverse-chronological order, answering 'what happened recently in this log?'. This specific verb-resource-purpose distinguishes it from sibling tools like abstract_variants or abstract_dfg, which compute different representations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quickly viewing recent events without computing variants or models, offering a lightweight alternative. However, it lacks explicit when-to-use or when-not-to-use guidance compared to other abstract 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?
No annotations provided, so description carries burden. Describes return value (handle for visualization + shape summary) but omits side effects, permissions, or performance characteristics. Adequate but could be more transparent.
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, no superfluous content. Front-loads purpose and adds key output details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and an output schema existing, the description covers core purpose and return behavior. Slight lack of context about prerequisites or relationship to sibling tools, but generally sufficient for a simple discovery 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?
Only one parameter (log_id) with 0% schema description coverage. The description does not elaborate on the parameter's meaning, format, or role beyond its name. Provides no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it discovers the directly-follows graph (DFG) of an event log. Distinguishes from sibling tools like visualize_dfg (rendering) and other discovery tools (Petri net, process tree, etc.). Verb+resource is specific.
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 vs. alternatives or prerequisites. Implies usage for DFG discovery but doesn't compare with other discovery tools or mention required prior steps (e.g., loading event log).
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. Describes return value (handle and shape summary) but does not disclose side effects, authorization needs, or whether it's read-only. For a discovery tool, likely non-destructive, but not explicit. Adequately transparent given the simple nature.
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 purpose, followed by concise details on return value. No extraneous information. 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 one required parameter and presence of an output schema, the description covers purpose and return value sufficiently. It mentions shape summary details (activity count, object types, edge counts), which is good. Could be slightly more specific about the handle, but overall complete for a discovery 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?
Schema has 0% description coverage, and the tool description does not describe the only parameter (ocel_id). Description adds no meaning beyond the schema's property name and type. The agent receives no guidance on what value to provide for ocel_id.
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 discovers an object-centric directly-follows graph (OC-DFG). The description distinguishes it from sibling tools like discover_dfg (which is for regular event logs) by specifying object-centric nature. It also mentions returning a handle for later visualization, which is unique.
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?
Implies usage for OC-DFG discovery but does not explicitly state when to use vs alternatives like discover_oc_petri_net or discover_dfg. The mention of 'later rendering via visualize_ocdfg' provides context but no exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the return value structure (handle, root operator name, child count) and mentions the variant selection default, but does not discuss side effects, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two paragraphs covering purpose and return details. Slightly longer than necessary but generally 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 the single parameter, the description explains the output schema but fails to clarify what `log_id` represents. The mention of a non-existent `variant` parameter detracts from completeness.
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%. The description does not explain the only parameter `log_id`, and introduces `variant` which is not in the input schema, causing confusion. No semantic value added for 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 identifies the tool as discovering a POWL model and explains its specific use case for partial-order dependencies, distinguishing it from other process discovery tools like discover_process_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Useful when the discovered model has unclear sibling ordering,' providing a clear when-to-use condition. However, it does not explicitly exclude alternatives or discuss 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses format constraints and path behavior but omits key traits like whether existing files are overwritten or error conditions. Partial 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 sentences plus a code block. The main action is front-loaded, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required params, no annotations, and an output schema, the description covers format and path but not 'ocel_id' semantics, prerequisites, or error handling. Adequate but incomplete for safe 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?
Schema coverage is 0%, so description must compensate. It explains format options and path resolution, improving on bare schema. However, 'ocel_id' remains unexplained, leaving a 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 tool writes an OCEL from registry to disk, with a specific verb and resource. It distinguishes from sibling 'export_log' which targets event logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides format and path rules but lacks explicit guidance on when to use this tool versus alternatives like export_log. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states that the full per-case list is NOT returned and explains why (potential large size). It also lists all returned statistics, providing good 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. The first sentence clearly states the purpose, and the second adds critical behavioral information. No filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, return values (with specifics), and an important behavioral constraint (not returning full list). It has an output schema, so return format is covered. For a simple statistics tool, this is 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?
The input schema has only one parameter (log_id) with no description, and schema coverage is 0%. The description does not elaborate on what log_id represents or any constraints. With low coverage, the description should compensate, but it does not, leaving the parameter's meaning to inference.
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 that the tool returns summary statistics for per-case durations, listing specific metrics like count, min, max, mean, median, and percentiles. It uses a specific verb 'return' and resource 'summary statistics'. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as tools that return full per-case lists or other summary statistics. The context implies it's for aggregate analysis, but no exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions wrapping a function but omits details on side effects, error handling, or permissions. The return value is not characterized beyond 'textual description'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: purpose, constraint/reference, and usage guidance. No unnecessary words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose and use context. However, with no schema descriptions for two parameters and no annotation support, the description falls short of fully enabling correct invocation, especially for parameters like max_len.
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 should explain parameters. Only object_type is described (must be a valid OCEL object type). ocel_id and max_len are not mentioned, leaving their meaning and usage unclear.
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 provides a textual description of OCEL features for a single object type, distinguishing it from sibling abstract_* tools that target different aspects. It uses specific verb 'describe' and resource 'OCEL features'.
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 advises using this tool before deciding which object type to flatten, providing a clear use case. It also references describe_ocel for valid object types, but does not explicitly exclude any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explains the behavioral output: returns a handle and number of pairs observed, and describes the computation method (mean/std per pair). It does not cover side effects or permissions, but the behavioral insight is sufficient for a read-only analysis 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 with three sentences, each serving a clear purpose: state the main function, detail the output, and note the use case. No extraneous information is included.
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 existence of an output schema and the tool's simplicity (single parameter, straightforward computation), the description is nearly complete. However, the missing parameter explanation is a notable gap that affects completeness.
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 only one parameter 'log_id' with 0% schema description coverage. The description fails to mention or explain this parameter, leaving the agent without guidance on what to provide.
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: discovering a temporal profile of per-activity-pair sojourn time statistics (mean and stddev). It distinguishes from siblings like 'abstract_temporal_profile' by specifying the exact computation and output.
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 the tool is 'useful for anomaly detection' but does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance. Usage context is implied 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?
With no annotations provided, the description carries the full burden. It discloses the exception for unsupported object_type, which is a behavioral trait. However, it does not state whether the operation is read-only or if modifications occur, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value (purpose, composability, exception). No waste.
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 two parameters and no annotations, the description covers the exception and composability context. However, it lacks a definition of 'traditional log handle' and does not explain the parameters' expected values, making it adequate but not fully 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 only adds context for object_type by mentioning the exception, but ocel_id is not elaborated upon. This adds minimal meaning beyond the 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 the tool's action: 'Project an OCEL onto a single object type and return a traditional log handle.' This is a specific verb+resource combination that distinguishes it from sibling tools that operate on OCEL without flattening.
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 it serves as a 'Phase 2 composability bridge' and the resulting log_id works with Phase 1 tools. This implies it should be used when a traditional log format is needed, but it does not explicitly state when to use it versus alternatives like filter_ocel_object_types which keep the OCEL format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the external dependency on Graphviz binaries and the PNG-only output format. It does not mention any side effects or data mutation, which is acceptable for a read-only visualization tool. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, concise and front-loaded with the main action. It efficiently covers purpose, parameter guidance, and external requirements. Minor improvement could be structuring with bullet points, but overall it earns 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?
Given the tool has 2 parameters, no output schema, and no annotations, the description covers purpose and parameter guidance adequately. However, it lacks details on the output image content, interpretation, or potential errors (e.g., missing Graphviz binaries). A more complete description would mention these aspects.
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 adds meaning to 'activities' by stating it should be a subset of activities, typically from the dominant variant. However, 'log_id' is not elaborated beyond the schema, leaving a gap. The description adds some value but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a performance spectrum using Graphviz/neato, plotting case durations along activities to reveal bottlenecks, with PNG-only output. The purpose is specific, but it does not explicitly differentiate this from sibling visualization tools like visualize_dotted_chart or visualize_dfg.
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 that 'activities' is required and should be a meaningful subset, typically from dominant variants, and that Graphviz binaries are needed. However, it does not indicate when to prefer this tool over alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions output format (PNG+SVG) but lacks details on side effects, permissions, error handling, or return behavior. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with action and resource. Every word earns 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?
For a simple one-parameter tool with no output schema, the description covers the core purpose. However, it lacks details on validation (e.g., what if petri_id is invalid) and how the PNG+SVG output is delivered. Somewhat adequate but not fully 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 coverage is 0%, and the description adds little meaning beyond the parameter name. It references 'from discover_petri_net' which hints at the source of petri_id, but does not explain the format or how to obtain it. The description does not adequately compensate 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?
Description clearly states the tool renders a Petri net (from discover_petri_net) as PNG+SVG. The verb 'Render' and resource 'Petri net' are specific, and the source distinguishes it from other visualization siblings like visualize_dfg or visualize_bpmn.
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?
Implies usage after discover_petri_net, giving clear context. Does not explicitly state when not to use or list alternatives, but the source reference effectively differentiates it from other visualization 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 explains the output (a weighted network) and its interpretation. It does not state whether the tool is read-only or safe, but the nature of discovery tools implies non-destructive analysis. The behavioral description is clear but could explicitly mention that no data is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the primary function, second adds interpretation and comparison. Every word adds value, no fluff. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 3 parameters with 0% schema description coverage and no annotations, the description fails to provide essential parameter guidance. Although an output schema exists (does not need return explanation), the lack of parameter documentation makes the tool definition incomplete for an agent to invoke 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 input schema provides no descriptions for parameters. The tool description does not mention any parameter names or roles, leaving the agent to guess the meaning of log_id, activity_key, and resource_key. This is a critical 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 tool discovers an activity-based resource-similarity network, defines edge as weighted similarity of activity profiles, and interprets it as 'who does similar kinds of work'. It distinguishes from handover network by noting complementarity. This is specific and actionable.
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 it 'complements handover by showing skill/role overlap', providing a clear use case and differentiation from a sibling tool (discover_handover_network). However, it does not provide comprehensive when-to-use/when-not-to-use guidance for all 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 carries full burden. It states the return value ('a handle to the tree plus its structural shape') but omits details like side effects, error conditions, or prerequisites (e.g., log must be loaded). The core behavior is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, no wasted words. It front-loads the main action and provides valuable supplementary info (composition, conversion, return value) efficiently.
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 (2 parameters, output schema exists), the description covers the main points: algorithm used, output type, and conversion properties. It could mention prerequisite log loading, but overall is complete enough.
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 parameters (log_id, noise_threshold). It does not add meaning beyond the input schema, failing to compensate for 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 purpose: 'Discover a process tree via the Inductive Miner.' It distinguishes from siblings by specifying the algorithm and output type (process tree vs Petri net, BPMN, etc.). Additional context about composition and conversion reinforces purpose.
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 for when to use this tool by highlighting that process trees compose cleanly and convert to other models. However, it does not explicitly state when to choose this over sibling discovery tools or give exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It explains how performance is measured and that it filters non-destructively, but doesn't address side effects, permissions, or return format. 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?
Two concise sentences that front-load the purpose and follow up with the metric definition and usage hint. 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?
Given the tool's complexity (3 parameters, filter operation, output schema present), the description covers the essential functionality. It lacks details on output format, but output schema likely fills that gap. Scores high for providing a clear, self-contained explanation.
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%, so the description must compensate. It implies min_seconds and max_seconds as the range but doesn't explain log_id or provide details on parameter constraints (e.g., non-negative values, inclusive/exclusive bounds). Minimal additional meaning over raw 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 filters cases based on total elapsed time, with a specific verb 'Keep only cases' and resource 'cases' defined by a performance metric. It distinguishes itself from sibling filter tools like filter_variants or filter_attribute_values by focusing on case duration.
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 it's 'useful for isolating slow or fast cases,' giving a hint of usage context. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., filter_time_range or filter_case_size) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that it uses Graphviz/neato, outputs PNG, and requires binaries, but does not disclose side effects, performance implications, or error handling for missing dependencies.
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 4-sentence paragraph, front-loaded with purpose, no redundant information, and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, parameters, and dependencies, but lacks explicit mention of return value format (e.g., how the PNG is returned) and does not address error cases or prerequisites beyond Graphviz.
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?
Explains the `attributes` parameter with default and examples, adding meaning beyond the schema, but does not describe the `log_id` parameter, leaving it with only schema 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?
Clearly states it renders a dotted chart, explains it's a time-vs-value scatter plot using attributes, and distinguishes from sibling tools like visualize_dfg or visualize_process_tree by its specific chart type and default behavior.
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?
Suggests default attributes as 'most useful view on an unfamiliar log', implying a use case for exploration, but does not explicitly compare to alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output as PNG and SVG, but no annotations provided, and does not confirm read-only nature or describe side effects beyond rendering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, direct sentence with no unnecessary words, immediately communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple rendering tool, but missing description of return format (e.g., inline vs. link) and could mention that both PNG and SVG are included.
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?
Single parameter ocpn_id is not described in schema; description hints it comes from discover_oc_petri_net but does not explain format 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?
Clear verb 'Render', specific resource 'object-centric Petri net', and distinguishes from siblings like visualize_petri_net by mentioning the source discover_oc_petri_net.
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?
Implies usage after discover_oc_petri_net but lacks explicit when-to-use vs. alternatives like visualize_petri_net or visualize_dfg.
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. Description explains it returns average cycle time at process level, but does not specify if it's a single value or per-case, nor the time range scope. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose, no redundant information, and efficient use of text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with output schema covering return structure, but missing parameter semantics and behavioral details about scope. Adequate for a basic retrieval but could be more 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 coverage is 0% with no description of the required log_id parameter. Description does not explain what log_id is or its format, leaving a significant gap for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states tool returns average cycle time, defines it as 'seconds between case completions', and explicitly distinguishes from sibling get_case_durations.
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 contrasts with get_case_durations, indicating this is for throughput measurement and capacity planning, but does not provide explicit when-not-to-use or alternatives beyond the stated sibling.
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 must carry the burden. It implies a read-only operation by stating 'Return the frequency,' but does not explicitly confirm non-destructive behavior or other traits. It's adequate but not explicit.
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, using only two sentences to convey the purpose and output format. No unnecessary words, and the key information is front-loaded.
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 simple tool (one parameter, output schema present), the description adequately covers the purpose, output structure (two dicts), and use case. No critical gaps remain.
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 the 'log_id' parameter at all. The parameter remains undefined, providing no meaning beyond the schema's name and type.
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 returns frequency of start and end activities across all cases, using specific verbs and resource. It distinguishes from siblings like 'get_variants' or 'get_case_durations' by focusing on start/end activities.
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 use case: 'useful for spotting unexpected entry/exit points in a process.' This gives context for when to use it, though it does not explicitly state when to avoid it or mention 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?
No annotations provided; description states output formats but does not disclose other behavioral traits like side effects or permissions. As a rendering tool, it is likely safe, but lacks explicit statements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads purpose with no wasted words; highly concise.
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 one-param tool without output schema, description adequately states purpose and output format, but could mention that output is images and clarify the ID source more explicitly.
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?
Single parameter 'bpmn_id' has no description in schema (0% coverage). Description hints it comes from discover_bpmn but does not explain format or how to obtain the ID.
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 'Render', the resource 'BPMN diagram', specifies it comes from 'discover_bpmn', and lists output formats 'PNG + SVG', distinguishing it from sibling visualization tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage after discover_bpmn but lacks explicit guidance on when not to use it or alternatives among other visualization 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?
With no annotations provided, the description carries the full burden. It discloses that it is 'Graphviz-backed' and describes what the diagram shows (partial-order edges, root operator in caption). However, it does not mention side effects, permissions, or error states. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the core purpose. Every sentence adds value: output format, implementation backend, and diagram content. 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?
For a simple tool with one parameter and no output schema, the description covers the key aspects: input (POWL model ID), output (PNG/SVG), and visual content. It implicitly indicates the prerequisite of discover_powl. Minor omission: no mention of file size limitations or accessibility of output images.
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 compensates partially. It adds context that the powl_id comes from discover_powl, meaning it refers to a previously discovered model. This adds meaning beyond the raw schema field, but could be more explicit about the nature of the identifier.
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 'Render' and the resource 'POWL model', specifying the output formats 'PNG + SVG'. It distinguishes from sibling visualization tools (e.g., visualize_petri_net) by explicitly mentioning the model type and the source tool discover_powl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (after discover_powl) and mentions Graphviz-backed rendering, but does not explicitly state when to use this tool versus alternatives like visualize_petri_net. No exclusions or conditional guidance 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?
No annotations are provided, so the description carries full burden. It states output formats (PNG+SVG) but does not disclose side effects, error handling, or whether it's read-only. The behavior is partially transparent but lacks detail on what 'render' entails (e.g., returns files, displays, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, perfectly concise sentence that front-loads the action and output. No superfluous words. It earns its place by being direct and informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema, no annotations), the description covers the basic purpose but lacks details on the output (e.g., are PNG and SVG files returned as URLs or base64?), error handling, and prerequisites. It is sufficient for a simple tool but not fully 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 has one required parameter 'tree_id' with 0% description coverage. The only hint in the description is 'from discover_process_tree', which implies the origin of the ID but does not explain its format, constraints, or how to obtain it. The schema itself offers no additional details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Render'), the resource ('process tree'), and the outputs ('PNG + SVG'). It references the source tool 'discover_process_tree', distinguishing it from sibling visualization tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after discovering a process tree. While it doesn't explicitly say when not to use or list alternatives, the context of sibling tools provides clarity. No explicit prerequisites are mentioned, but the single parameter 'tree_id' hints at the need for a prior discovery result.
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 reveals that pm4py computes the OCDFG internally, which adds transparency about processing. However, it does not disclose other behaviors like performance impact, side effects, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note; no wasted words. The key information is front-loaded. Could be slightly more structured with a list of parameters, but 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?
Given 3 parameters with no description for 2, and an output schema existing but not detailed in the description, the agent gets partial guidance. The reference to alternative tools helps, but lack of parameter details hurts completeness for a moderately complex tool.
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 description must compensate. It only mentions 'ocel_id' and that it is different from 'ocdfg_id'. The other two parameters (max_len, include_performance) are not explained, leaving semantic gaps for the agent.
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 produces an 'Object-centric directly-follows graph as text.' It distinguishes from siblings by specifying it takes 'ocel_id' not 'ocdfg_id' and contrasts with the discover_ocdfg/visualize_ocdfg pair for rendered output.
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 tells when not to use (for rendered version) and provides alternative: 'use Phase 2's discover_ocdfg → visualize_ocdfg pair.' Also clarifies the parameter difference (ocel_id vs ocdfg_id), preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses internal wrapping (net_to_descr) and the behavioral trait that 'truncated' is always false due to missing MAX_LEN parameter. No contradictory information, but could mention read-only nature or return format beyond enumeration.
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 four sentences, each adding value: purpose, internal mechanism, output elements, and a behavioral note. No redundancy or fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and output schema presence, the description covers the main purpose, input source, output content, and a relevant behavioral detail. It is sufficient for decision-making, though could mention that the output is textual and what the output schema provides.
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 sole parameter 'petri_id' has 0% schema description coverage. The description hints it's an identifier from discover_petri_net but does not explain format, origin, or validity rules. More explicit parameter guidance is needed to compensate for 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 'Describe' and resource 'Petri net', specifying it takes a net from 'discover_petri_net'. It distinguishes from siblings (other abstract_* and visualize_petri_net) by focusing on natural language output and enumerating specific elements (places, transitions, arcs, markings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after discovering a Petri net ('from discover_petri_net') and notes that truncation never occurs. However, it lacks explicit when-to-use vs alternatives, such as comparing to visualize_petri_net or other abstract tools. No exclusions or prerequisites are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavioral traits: it reports specific connectivity metrics (top-k connections, sinks, sources) and clarifies that truncated is always False. However, it does not mention whether the operation is read-only or any side effects, though the nature suggests it is safe. There is no contradiction with missing annotations.
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 front-loaded purpose and bullet points for reported items. It is concise without unnecessary fluff, though it could be slightly shorter. Each sentence contributes value, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but context indicates true), the description does not need to detail return values. It adequately explains the input (sna_id, top_k), the output structure (listed stats), and the relationship to discovery tools. It is complete for a simple tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly explains top_k by stating it bounds the strongest connections, but it does not describe sna_id beyond implying it is a handle from a discovery tool. The description adds some meaning but not enough to fully cover the parameters, given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Describe the top-k connections of a social-network (SNA) model in prose.' It specifies the resource (SNA model) and the action (describe top-k connections), distinguishing it from sibling abstract tools like abstract_log_attributes or abstract_variants, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing which discovery tool outputs are valid inputs (e.g., discover_handover_network, discover_working_together_network). It implicitly tells when to use this tool (after those discovery steps) and notes that 'truncated is always False.' However, it does not explicitly exclude when not to use or mention alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses re-computation on demand, the eviction behavior (1-hour TTL or LRU overflow), and the error exception ('HandleNotFound'). It could mention read-only nature but is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste, front-loading the core purpose. It uses technical terms efficiently without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately focuses on non-obvious details (re-computation, eviction, error). It could be improved by explicitly linking the parameter to a prior action, but is largely complete for a simple retrieval tool.
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?
With schema description coverage at 0%, the tool description does not explain the 'ocel_id' parameter beyond the implicit context of 'previously loaded OCEL'. It fails to specify what value to use (e.g., the ID from load_ocel's response), leaving the agent to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and resource 'compact summary for a previously loaded OCEL', distinguishing it from siblings like 'describe_log' (for logs) and 'load_ocel' (which returns summary on load, not on demand).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving an OCEL summary on demand after loading, but does not explicitly state when to use versus alternatives like 'describe_log' or address prerequisites (e.g., must have called 'load_ocel' first).
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 mentions the output (handle and counts) and variant behavior, but does not disclose permissions, side effects, or prerequisites. The behavioral traits are partially covered.
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 three sentences: purpose, variant explanation, and output summary. It is front-loaded and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the high-level return description is acceptable. However, the 'ocel_id' parameter is not explained, and the concept of a 'handle' is undefined. The description is adequate but has minor 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%, but the description adds meaning for the 'variant' parameter by explaining the two options and their trade-offs. However, it does not describe the 'ocel_id' parameter beyond its schema definition. This adds value but is incomplete.
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 discovers an object-centric Petri net (OCPN), with a specific verb 'Discover' and resource 'object-centric Petri net'. It distinguishes from sibling tools like 'discover_petri_net' by specifying 'object-centric'. The variant options are also explained, adding specificity.
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 use for object-centric event logs but does not explicitly state when to use this tool over alternatives like 'discover_petri_net'. It describes the variant trade-off (im vs imd) but lacks explicit when-not or alternative recommendations.
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 behavioral burden. It discloses that truncated is always False, explains drop_nan_attrs behavior and its token-saving impact, and references the backend library. However, it does not mention side effects or permissions, but for a read-like operation this is reasonable.
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?
Four focused sentences with clear formatting (uses code blocks) and no redundant information. Every sentence adds meaningful detail, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists for return values, the description covers purpose, two key parameters, and a behavioral note. Missing include_event_attributes explanation is the only gap, but overall it provides sufficient context for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains case_id (must match column value) and drop_nan_attrs (default True, new feature, effect on output). However, log_id and include_event_attributes are unexplained, leaving 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?
The description clearly states 'Describe one case as a natural-language walkthrough of its events,' specifying the verb and resource. It distinguishes from sibling abstract_* tools by focusing on a single case, unlike abstract_variants or abstract_log_attributes.
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 use for a single case but does not explicitly provide when-to-use or when-not-to-use compared to alternatives. No exclusions or conditions are mentioned, leaving the agent to infer 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?
With no annotations, the description discloses algorithmic behavior (three miners) and return format (net, marking, counts) but does not state side effects (e.g., read-only, persistence) or permissions. Provides moderate 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, well-structured with a clear first-line purpose, bulleted algorithm details, and a final sentence on output. No unnecessary words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description sufficiently covers the return value and algorithmic details. However, it does not mention that log_id must refer to an existing event log (precondition), leaving a minor gap.
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?
Despite 0% schema description coverage, the description adds meaning to all three parameters: log_id is implied, algorithm is explained with behavior, and noise_threshold is constrained to [0,1] for inductive. Effectively compensates for 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 tool discovers a Petri net from an event log, specifies three algorithms with distinct characteristics, and distinguishes from sibling discovery tools (e.g., discover_dfg, discover_process_tree) by focusing on Petri net output.
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 algorithm options and parameters but lacks explicit guidance on when to choose one algorithm over another or when to use this tool vs alternatives like discover_process_tree. Usage context is implied but not clearly directed.
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 effectively discloses the format constraint ('must be xes or csv') and path resolution logic (workspace vs absolute/relative). This goes beyond the schema and provides useful behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a few lines are entirely sufficient. No fluff, front-loaded with purpose, and structured for easy reading.
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, an output schema exists (reducing need to describe return), and the description covers key usage details. Missing log_id explanation and file overwrite behavior, but still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It clarifies the format and path parameters (allowed values, path behavior) but does not mention the log_id parameter. Partial coverage, adequate for 2 of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write a log from the registry to disk.' It uses a specific verb ('Write') and resource ('log from registry'), and is distinct from siblings which are mostly abstract or discovery tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a log_id and want to save to disk) but does not explicitly state when to use this tool versus alternatives like load_event_log. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It clearly details the different behaviors for level and retain parameters, and even warns about a deprecation issue with PM4Py. However, it does not specify whether the tool modifies the log in place or returns a new filtered log, which is relevant for understanding 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 concise (four sentences) with the core purpose in the first sentence. Subsequent sentences efficiently explain key parameters and a practical nuance (deprecation warning). No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be described) and the moderate complexity (5 parameters, 3 required), the description covers the essential filtering behavior and parameter effects. It could be slightly more complete by elaborating on the attribute and values parameters or providing an example.
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 explains level and retain well, but provides minimal explanation for required parameters like attribute and values (only implicit from 'filter by attribute values'). Log_id is left unexplained. Thus, it adds some value but not enough to fully cover all 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 filters a log by attribute values at event or case level, and the name 'filter_attribute_values' aligns with this. It effectively distinguishes the filtering functionality from sibling tools like filter_variants or filter_time_range by specifying the attribute-based criterion.
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 each level (event vs. case) and the effect of retain (keep vs. drop). However, it does not explicitly guide when to use this tool over other filtering siblings (e.g., filter_time_range for temporal filters), nor does it mention prerequisites or limitations.
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, so description carries full burden. Discloses output format (PNG, SVG), coloring by object type, and default frequency annotations. Adds useful behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose and key features without redundancy. Front-loaded verb 'Render' and efficient use of parentheses for format.
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 core functionality and output traits for a visualization tool. Lacks details on output delivery (URL vs base64) but is sufficient given the single parameter and lack of customization options.
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?
Only one parameter 'ocdfg_id' with 0% schema documentation. Description does not explicitly define it, but tool context and name imply it is an identifier from discover_ocdfg. Adequate for a single required 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?
Description clearly states it renders an OC-DFG as PNG+SVG, specifying the source from 'discover_ocdfg'. This distinctly separates it from sibling visualization tools like 'visualize_dfg' or 'visualize_petri_net'.
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?
Implies usage after discovering an OC-DFG, but no explicit guidance on when to use vs alternatives. Lacks conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses internal implementation (wraps tempprofile_to_descr.apply), explains that the profile dict uses Tuple[str, str] keys which are internally formatted and never exposed as raw tuples to JSON, and states that no MAX_LEN parameter exists. This provides useful behavioral context beyond a simple function call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding essential information: purpose, input source, internal handling, and a key constraint. No superfluous words, and the most important point 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 presence of an output schema, the description appropriately does not detail return values. It covers the input, internal processing, and output nature. However, it lacks mention of possible errors or prerequisites beyond having the handle, which would improve completeness for a tool with only one input.
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 the single parameter 'temporal_profile_id' is the handle returned by discover_temporal_profile, adding meaning beyond the input schema (which has no description). This helps the agent understand the value's origin and expected type. Given schema description coverage is 0%, the description effectively compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Natural-language description of a discovered temporal profile' and clarifies it takes a handle from discover_temporal_profile. This clearly identifies the tool's purpose and resource, but does not explicitly distinguish it from all sibling tools beyond discover_temporal_profile.
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 'Takes the handle returned by discover_temporal_profile', establishing a clear prerequisite. It also notes 'No MAX_LEN parameter; full profile is described', providing guidance on when to use this tool over a potential truncated variant. However, it does not list alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It discloses that the response is compact and returns only mean fitness and count, and that detailed diagnostics require a different approach. This sets clear expectations for 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 concise with three sentences, front-loading the purpose. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description adequately explains the return values (mean fitness, count) and notes the compact response. It does not cover prerequisites or error cases, but for a technical conformance tool, it provides sufficient context to use it correctly.
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% and the description does not explain the two parameters (log_id, petri_id). It relies on domain knowledge, which may be insufficient for an AI agent unfamiliar with the context. The description adds no semantic 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 specifies the tool performs a token-based replay conformance check, returning mean trace fitness and count of perfectly-fit traces. It distinguishes from sibling conformance_alignments by naming the method (token replay).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for conformance checking and mentions that for detailed per-trace diagnostics, users should use PM4Py directly, indicating when to use this tool vs a more detailed alternative. However, it does not explicitly state when to prefer token replay over other conformance methods like alignments.
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 discloses a key behavioral trait: filtering object types also removes 'every event that only touched them', which is important for understanding side effects. Without annotations, this adds significant value, though it could mention more details about edge cases or scope.
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 with one sentence and an example, but the example is code-like and could be better integrated. It front-loads the main purpose, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the main behavior and parameter intent. It could be slightly more thorough about the effect on the OCEL structure, but overall it is reasonably complete for a filter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description partially compensates by explaining the 'types' and 'retain' parameters via example and behavior. However, it does not describe the 'ocel_id' parameter, leaving a gap for one of the three 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 states 'Keep or drop entire object types (and every event that only touched them)', which clearly specifies the verb (keep/drop) and resource (object types). It distinguishes from siblings like filter_ocel_time_range and filter_ocel_attribute by focusing specifically on object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two usage modes with retain=True and retain=False, providing a concrete example. While it doesn't explicitly mention when not to use this tool or list alternatives, the context from sibling names makes the differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool wraps a specific function and clarifies that 'truncated' is always False due to pm4py limitations. However, it does not discuss error handling, permissions, 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?
Three sentences efficiently convey purpose, prerequisite, and a behavioral nuance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is adequate. It explains the input source and the behavior of a key field, leaving details of the return format to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to the sole parameter 'declare_id' by stating it is a handle from discover_declare, which is essential context beyond the raw 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 provides a natural-language description of a discovered DECLARE model, using a handle from discover_declare. This differentiates it from sibling abstract_ tools for other model types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the prerequisite of calling discover_declare first. Provides context on the 'truncated' field behavior, but does not explicitly state when not to use it or list 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 carries the full burden. It discloses key behaviors: it takes log_id, computes DFG internally, and returns text. A slightly higher score would require mention of side effects or output format, but it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. Key information is front-loaded: the core function first, followed by critical notes on parameters and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be detailed. However, two of three parameters lack semantic description, and the description does not cover the tool's full scope (e.g., what 'text' format means). It is adequate but incomplete.
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%, so the description must compensate. It only explains log_id (and its distinction from dfg_id). The other two parameters (max_len, include_performance) are not described in the description, leaving them semantically undocumented.
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 produces a text-based directly-follows graph, with explicit distinction from the visual PNG/SVG rendering via the discover_dfg/visualize_dfg pair. It specifies the unique input requirement (log_id not dfg_id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (text output) versus the alternative visual pipeline (discover_dfg + visualize_dfg). It also clarifies that pm4py internally computes the DFG, so no prior discovery step is needed.
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 discloses error behavior (raises InvalidKind for unsupported combos) and records lineage (new handle records source_handle). This is good behavioral context, but could mention if the conversion is destructive or non-destructive.
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 a clear structure including bullet points for supported pairs. No fluff, every sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description covers conversion logic, supported pairs, and error handling. It is largely complete, though it could briefly mention the return value type (e.g., new model handle) for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the description compensates by explaining what source_id is (any model handle) and listing the allowed values for target_kind. This adds meaning beyond the enum 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 converts a process model from one representation to another, specifies the two parameters (source_id and target_kind), and lists the supported conversion pairs. This differentiates it from sibling tools like discovery or filtering tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting between model types but does not explicitly state when to use or not use this tool, nor does it mention alternatives. It lacks guidance on prerequisites or contraindications.
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, so description carries full burden. It discloses potential failure (HandleNotFound if log evicted), caching behavior (1-hour TTL or LRU), and re-computation on demand. Lacks auth or side-effect details, but adequate for a 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, front-loaded with purpose, second sentence adds behavioral detail. No redundant information; each 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 one parameter, no nested objects, and presence of output schema, the description covers purpose, failure mode, and data retention. It could mention prerequisite call to load_event_log, but 'previously loaded log' implies 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 coverage is 0%, so description must compensate. It indicates log_id refers to a previously loaded log, adding context beyond the bare schema. However, it doesn't specify format or constraints on the ID.
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 returns a compact summary for a previously loaded log. It specifies the output is the same shape as the summary in load_event_log's response, distinguishing it from loading and other abstract tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after loading a log, but does not explicitly state when not to use it or list alternative tools. The context of siblings suggests alternatives for different abstractions, but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses that the tool dispatches to underlying PM4Py functions based on level and that retain controls inclusion/exclusion. This is adequate for a filter operation, though it does not mention if a new OCEL is returned or if the original is modified.
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 three sentences, no redundant information. It front-loads the purpose and adds detail in subsequent sentences. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required) and an output schema exists, the description covers the core filtering behavior and key parameters. However, it leaves ocel_id and attribute unexplained, which is a minor gap. Overall, it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains level and retain parameters, but ocel_id and attribute are not described despite being required. The description mentions attribute and values in the purpose clause, which provides some context, but not enough for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Filter an OCEL by event or object attribute values' which specifies the action and resource. It also explains the two levels and retain parameter, effectively distinguishing from sibling tools like filter_ocel_time_range or filter_ocel_object_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using level parameter to choose between event and object filtering and explains retain mapping to positive. However, it does not explicitly state when to use this tool versus other filter tools, such as filter_ocel_time_range, missing exclusion criteria.
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 behavioral traits: for longest/shortest strategies, the response includes an event_counts dict; first omits it. This is sufficient for a read-only sampling 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, using bullet points for strategies, and front-loads the purpose. 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?
The description covers core functionality, strategy differences, and output behavior (event_counts). It does not mention prerequisites or error handling, but the tool is simple and an output schema exists.
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%, but the description adds meaning for the strategy parameter by listing enum values and their implications. It does not explicitly describe n (though the name is clear) or log_id, partially compensating for 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 the tool returns a sample of case IDs from a log, with explicit mention of its utility for feeding into abstract_case. This distinguishes it from abstract_* siblings by specifying the resource and verb.
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 the tool (to pick a concrete case_id without exporting the log) and describes three strategies. It does not explicitly state when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool stores data under a fresh handle, infers format from extension, never returns the OCEL directly, and returns a summary dict. This is comprehensive and lacks contradictions.
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 two paragraphs, front-loading the main action and format inference, then providing return details and sibling guidance. It is efficient with no unnecessary words, though it could be slightly more concise by merging the format list into the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, clear output schema presence), the description covers the essential aspects: input, behavior, output summary, and subsequent usage. It is complete enough for an AI agent to understand usage, though it could mention the output schema explicitly.
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 explains the path parameter implicitly by mentioning file extensions and reading from disk, but it does not explicitly state that 'path' is a required string for the local file path. More explicit parameter documentation would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read an OCEL 2.0 file from disk and store it under a fresh ocel_id handle.' It specifies the resource (OCEL 2.0 file) and the action (read and store). The mention of format inference and the return dict further clarify its purpose.
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 guidance on when to use this tool vs. flatten_ocel, saying 'Use flatten_ocel to project the OCEL onto a single object type and obtain a traditional log_id.' It also explains that this tool does not return the OCEL itself, setting expectations. However, it does not explicitly contrast with load_event_log or other load tools, so there is room for improvement.
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 behavioral traits: it is alignment-based (vs. token replay), can be slow, supports multi_processing (with Windows spawn restrictions), and emits progress events to keep requests alive. This covers safety (read-only) and performance characteristics comprehensively.
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) and front-loaded: purpose first, then trade-offs, then parameter caveats, then behavior. 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?
For a complex analysis tool with 3 parameters and an output schema, the description covers key aspects: purpose, performance trade-offs, platform restrictions, and timeout handling. It lacks explicit output description, but the presence of an output schema mitigates this. Sibling tools like 'conformance_token_replay' provide alternative context, but the description is largely self-sufficient.
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%, meaning the description must compensate by explaining parameters. However, it only elaborates on 'multi_processing' (its caveats) and does not explain 'log_id' or 'petri_id' beyond their implied role as identifiers. This leaves half of the parameters semantically under-described for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an 'Alignment-based conformance check,' which is a specific verb-resource combination. It distinguishes itself from the sibling tool 'conformance_token_replay' by noting it is more accurate but slower, effectively differentiating in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool versus alternatives: 'More accurate than token replay but slower — can take minutes on large logs.' It also mentions the multi_processing option with platform-specific caveats and progress events for timeout handling, offering clear context for 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, the description carries the full burden. It explains the behavior of each mode in detail, indicating how the filter applies to events vs traces. However, it does not clarify whether the tool modifies the log in place or returns a new log, nor does it mention permissions or side effects. The transparency is good 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 concise, with a one-line summary followed by a bulleted list of modes. Every sentence provides essential information, and the structure makes it easy to scan. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values do not need explanation. The description covers the key inputs and behaviors thoroughly, though it misses an explanation for the 'log_id' parameter. Given the moderate complexity and presence of an output schema, the description is largely complete but has a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It explains start and end as ISO-8601 strings and describes each mode value in detail. However, it omits an explanation of the required 'log_id' parameter, relying on the schema's title alone. Overall, it adds significant value for most 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's purpose: 'Filter a log by a time window.' It specifies the required start and end parameters as ISO-8601 strings and explains each mode option. This distinguishes it from sibling filter tools like filter_variants or filter_attribute_values, which focus on different aspects.
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 enumerates the mode parameter options with clear definitions, guiding the agent on when to use each mode (e.g., 'events' default, traces wholly or partially within window). It provides implied context for usage based on the desired time window semantics, but does not explicitly state when not to use this tool or mention 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 provided, the description carries the full burden. It discloses that exactly one of top_k and variants must be given, clarifies the effect of the retain boolean ('keep (or remove, if retain=False)'), and indicates the output is a filtered log (implicitly). No side effects, permission requirements, or error conditions are mentioned, but the core behavior is transparent.
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 single-line summary followed by a bulleted list explaining the two parameter options. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the core functionality, parameter usage, and the mutual exclusivity constraint. It could be improved by explicitly mentioning the required log_id parameter, but overall it is sufficiently complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains top_k, variants, and retain in detail with examples. However, log_id is required but not explicitly described; it is only implied as the log to filter. Overall, three of four parameters are well-covered.
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 begins with a clear verb+resource: 'Filter a log by trace variant.' This immediately distinguishes it from sibling filter tools that filter by attribute values, case size, or time range. The specification of 'trace variant' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two mutually exclusive usage modes (top_k vs. variants) and their typical applications: 'Useful for ignoring rare noise' for top_k and 'keep/remove specific variants' for variants. However, it does not state when not to use this tool or provide explicit alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: it lists files, reports specific metadata, and clarifies that subdirectories are not recursed. This is sufficient for a read-only listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the main purpose and then add specific details. Every sentence provides value, and there is 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 no parameters and an output schema exists, the description covers all necessary behavioral aspects: what is listed, what fields are reported, and how subdirectories are handled. It is fully adequate for a simple listing 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?
There are no parameters, so schema coverage is 100% (vacuously). The description does not need to add parameter info but provides context about the output. A baseline of 3 is appropriate, and the description exceeds it by specifying what each entry contains.
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 lists files in the workspace directory, specifies the reported fields (name, absolute path, size, modification time), and notes that subdirectories are listed by name but not recursed. This is a specific verb-resource combination with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (to list workspace files) but does not provide comparison to sibling tools. However, since no sibling tool serves a similar purpose, the lack of alternatives is 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?
Discloses the return values (server name and version) and implies read-only behavior. No annotation provided, but description covers essential traits.
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 purpose and return 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?
For a zero-parameter tool with output schema, the description fully explains what the tool does and when to use it.
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, so baseline is 4. The description adds value by specifying what the tool returns.
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 is a health-check that returns server name and version, distinguishing it from sibling process mining 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?
Explicitly mentions use cases: testing pyramid verification and manual reachability check after installation. No exclusions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes image embedding, linking, whitespace stripping, output path behavior, and return dict. Annotations absent, so description carries full burden and does it well.
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 headings and lists, informative yet not verbose. Could be slightly more concise, but clarity is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameter behavior, optionality, output schema, and usage expectations. No gaps given 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 has 0% description coverage; description provides detailed explanations for all 4 parameters, including roles, formats, and 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?
States clearly it assembles a Markdown executive report from prose findings and artifact links. Distinguishes from siblings which are about abstraction, discovery, filtering, etc.
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?
Advises to pass findings after calling abstract_*/get_* tools, giving clear context. Does not explicitly list when not to use, but siblings provide alternative contexts.
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 includes key behavioral details: the returned log_id is of kind 'log' and composes with Phase 1 tools, source_handle tracks lineage, and num_traces is capped at 10,000 to prevent runaway generation. It does not cover potential errors or performance, but the provided info is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It immediately states the purpose, then provides model-type constraints, behavioral details, and a limit on traces. Each sentence serves a clear purpose.
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 parameters, output schema exists) and no annotations, the description covers inputs, conversion requirements, output format, and constraints. It is self-contained and integrates well with sibling tools like convert_model and other discovery tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains model_id as a handle from a discovered Petri net or process tree, and num_traces with a default and cap. This adds significant meaning beyond the bare schema, though it could be more explicit about the source of valid handles.
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 simulates an event log by replaying a discovered model, specifying it accepts Petri net and process tree handles. This distinguishes it from siblings like abstract_* and conformance_* tools, which focus on analysis or checking, not simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on supported model types (Petri net, process tree) and unsupported ones (BPMN, POWL) with a conversion workaround via convert_model. It also mentions the num_traces cap. It lacks explicit 'when not to use' statements, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that the tool wraps a specific function and always returns the full skeleton without a MAX_LEN parameter. Without annotations, it provides good behavioral insight, though it does not mention side effects or permissions (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?
Extremely concise with no wasted words. Purpose is stated first, followed by additional details in a logical sequence. 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?
Complete for a simple tool with one parameter and an output schema. The description covers what the tool does, the source of the input, and a key behavioral trait (no MAX_LEN). No further information is needed.
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 single parameter 'log_skeleton_id' is explained as the handle from discover_log_skeleton, giving crucial context beyond the schema (which has 0% description coverage). This helps the agent correctly source the input.
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 provides a natural-language description of a discovered log skeleton. Specifies the input handle and the output (full skeleton in prose). Differentiates from sibling abstract tools by focusing specifically on log skeletons.
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?
Indicates the tool is used after discover_log_skeleton, providing the handle as input. Implicitly guides that this is for textual descriptions of log skeletons, but does not explicitly exclude other abstract tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses experimental status, dispatch behavior, and potential edge-case failures, adding significant context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points, front-loaded with purpose, and every sentence adds value without 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 complexity (4 params, experimental status, output schema exists), description is fully complete, covering strategies, values, and limitations.
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 fully explains every parameter's meaning based on strategy, including value types and retain behavior, adding substantial semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs connected-component filtering on OCELs, with specific strategies. It distinguishes from sibling OCEL filters by focusing on CC filtering.
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 each strategy and notes that retain is ignored for some. It does not explicitly exclude contexts but provides clear guidance on dispatches.
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 discloses format inference, supported formats, key parameters for CSV/Parquet, return type, and that it never returns the log itself. Lacks side effects or error info 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?
Concise and well-structured: purpose first, then format details, then key parameters, then return value. No unnecessary 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?
Covers all aspects: what the tool does, format support, parameter roles, return structure (dict with log_id and summary including counts, preview, time range, top variants). Output schema exists but description adds sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully compensates by explaining each parameter: path, format (inferred), *_key parameters as column mappings with defaults and 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?
Description clearly states 'Read an event log from disk and store it under a fresh log_id handle,' specifying the action and resource. It distinguishes from siblings which are mostly analysis or visualization 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?
Describes when to use (loading event logs), format inference, and that subsequent tools retrieve by handle. No explicit alternatives but context implies other load tools for different formats like load_ocel.
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 behavioral traits: overwriting on same name, prepending stored context to subsequent prompts, and explicit limits (20KB per context, 16 named contexts max). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, then details parameter behavior and limits. No wasted 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?
The tool has an output schema, so return values need not be explained. The description covers behavior, limits, and parameter semantics. It is complete for a storage/write tool, though a brief note on output (e.g., confirmation) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains text_or_path's dual interpretation (file vs inline). The 'name' parameter's default and overwrite behavior is implied but not explicitly detailed. Overall, adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register a domain context (SOP, glossary, process description) under name.' It uses specific verbs (register) and resources (domain context), and distinguishes from its sibling 'get_domain_context' by being the write counterpart.
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 the tool (registering context) and how text_or_path is interpreted. It also mentions overwrite behavior and prepending to prompts. While it does not explicitly state when not to use it, the presence of a sibling 'get' tool implies the set version for creation/update.
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:

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

Score Badge

Copy to your README.md:

[![pm4py-mcp MCP server](https://glama.ai/mcp/servers/azizketata/pm4py-mcp/badges/score.svg)](https://glama.ai/mcp/servers/azizketata/pm4py-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azizketata/pm4py-mcp'

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