Operaton MCP

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools have distinct purposes, with clear resource-action pairings (e.g., decision_deploy vs. decision_evaluate). However, some overlap exists in deployment and process definition tools (e.g., deployment_create and processDefinition_deploy both handle deployment), which could cause mild confusion, though descriptions help differentiate them.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear resource prefixes (e.g., decision_, deployment_, processDefinition_). This predictability makes it easy for agents to understand and navigate the toolset.
Tool Count2/5
With 105 tools, the count is excessive for a single server, making it overwhelming and difficult to manage. This many tools suggests poor scoping, as many could be consolidated or split into multiple focused servers for better usability.
Completeness5/5
The toolset provides comprehensive coverage for the Operaton domain, including full CRUD operations for decisions, deployments, processes, tasks, users, and groups, plus advanced features like migration, history, and incident management. There are no obvious gaps, supporting end-to-end workflows.
Average 3.7/5 across 105 of 105 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.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?
With no annotations provided, the description carries full disclosure burden. While 'advancing the process' hints at mutation, it fails to disclose whether this is destructive, if it requires task assignment first, idempotency characteristics, or what 'confirmation' entails. A state-changing workflow operation requires more behavioral context.
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 three-sentence structure is appropriately front-loaded, but the second sentence (regarding output variables) is misleading given the empty schema. The third sentence ('Returns confirmation') is vague. Length is appropriate but content accuracy is compromised.
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?
For a tool that transitions process state, the description is insufficient. It lacks explanation of how to identify the task (ID parameter missing from schema), the expected return structure beyond vague 'confirmation', side effects on process instances, and error scenarios. The empty schema combined with minimal description leaves critical 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?
The description claims one can 'optionally provide output variables,' but the input schema has zero parameters (empty properties object). This is a serious discrepancy that would mislead an agent into attempting to provide non-existent parameters. When schema coverage is 100% (vacuously true here), the baseline is 3, but this description contradicts the schema rather than complementing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Complete') and resource ('user task') and explains the outcome ('advancing the process'). It distinguishes from siblings like task_claim, task_delegate, and task_resolve by specifying the terminal action. However, it lacks BPMN-specific context about what completion entails (e.g., boundary events, variable submission).
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 fails to specify when to use this tool versus task_resolve or task_delegate, which are distinct completion-related actions in BPMN. More critically, it references 'optional output variables' that do not exist in the empty input schema, creating confusion about prerequisites and usage patterns.
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 full burden of behavioral disclosure. It adds valuable context that reasons are recorded in history and that confirmation is returned. However, it fails to clarify if the deletion is permanent/irreversible or what permissions are required for this destructive operation.
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 three-sentence structure is appropriately concise and front-loaded. However, the content inaccuracy regarding parameters undermines the structural efficiency.
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?
For a destructive operation with no annotations and an empty schema, the description is incomplete. It lacks safety warnings about irreversibility and the parameter/schema mismatch represents a critical documentation gap that would prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical mismatch: the description references 'by ID' and an 'optional deletion reason' parameter, but the input schema is completely empty (zero properties). This creates false expectations about required arguments and will mislead agents attempting to invoke the tool.
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 deletes/cancels an active process instance and distinguishes from sibling 'get', 'list', and 'start' operations via the specific verb. However, it mentions 'by ID' which implies a parameter requirement not reflected in the schema, creating slight confusion.
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 versus alternatives like processInstance_setSuspension or processDefinition_deleteById. The mention of 'active' instances provides minimal context but no explicit when/when-not rules.
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 bears full responsibility for behavioral disclosure. It mentions return values ('deployment metadata and deployed decision definition keys') which is helpful given no output schema exists, but fails to disclose critical mutation traits: whether deployment overwrites existing keys, versioning behavior, or error conditions for invalid DMN XML.
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 focused sentences: purpose statement, input requirements, and return value description. No filler text; every clause delivers specific operational information appropriate for the tool's complexity.
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?
Severely incomplete: empty input schema combined with unannotated behavior means the description should compensate with detailed parameter specifications and behavioral edge cases. It mentions expected inputs and outputs but lacks error handling, authentication requirements, or differentiation from similar deployment tools in the sibling list.
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?
Critical mismatch: schema defines 0 parameters while description explicitly instructs to 'Provide DMN XML, a .dmn filename, and a deployment name' (three specific inputs). Despite the 0-parameter baseline of 4, describing parameters that do not exist in the schema creates confusion about how the agent should populate the empty input object required for invocation.
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?
Clear specific verb (Deploy) and resource (DMN decision artifact). Distinguishes from generic siblings like 'deployment_create' by specifying 'DMN decision artifact', though it does not explicitly articulate the distinction between this tool and the generic deployment alternative.
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 provided on when to use this tool versus the generic 'deployment_create' sibling, nor does it mention prerequisites (e.g., valid DMN XML format requirements) or when to prefer alternatives like 'decision_evaluate'.
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 successfully communicates that suspended jobs won't execute and that resumption re-enables them, but lacks critical mutation context: no mention of idempotency, failure modes (e.g., job not found), or whether the change is persistent/reversible.
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?
Compact two-sentence structure with clear progression: first states the action and target, second explains the behavioral consequences. No redundant phrases, though mentioning 'by ID' when no such parameter exists wastes the agent's attention.
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?
For a state-mutation tool with no annotations and no output schema, the description is insufficient. The missing ID parameter in the schema makes the tool unusable as documented, and there's no coverage of error cases, prerequisites, or side effects expected for suspension operations.
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?
Despite 0 parameters (which typically warrants a baseline of 4), the description references an 'ID' parameter that doesn't exist in the schema. This contradiction creates confusion about how to specify the target job, downgrading the score from the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (suspend/resume) and resource (job), and distinguishes from job-definitions by specifying 'specific job'. However, it claims the tool operates 'by ID' while the input schema has zero parameters, creating a critical mismatch that impedes correct invocation.
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?
Explains the behavioral effect of suspension (execution blocking) and resumption, but fails to distinguish from the sibling tool 'jobDefinition_setSuspension' despite the similar naming pattern. No guidance on when to use job-level vs definition-level suspension.
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 return values ('deployment metadata and deployed definition keys') which helps given the lack of output schema, but omits critical behavioral details required for a mutation tool without annotations: idempotency, handling of duplicate definitions, validation errors, or side effects on the server.
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?
Three sentences efficiently structured: action definition, input requirements, and return value. No redundant phrases, though the null title wastes the opportunity for a concise label.
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?
For a deployment operation (high complexity, no annotations, no output schema), the description is insufficient. It lacks versioning behavior, error handling patterns, and the critical distinction from generic deployment siblings necessary for safe agent operation.
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 an empty input schema (0 parameters), the description attempts to compensate by listing three expected inputs ('BPMN or DMN XML', 'filename', 'deployment name'), but fails to explain their formats, relationships, or validation rules. The disconnect between described parameters and empty schema creates ambiguity.
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?
Specific verb 'Deploy' and resource 'BPMN process definition' are stated, plus the target system 'Operaton'. However, it mentions handling DMN XML as well, which overlaps with the `decision_deploy` sibling without clarifying the distinction, and the null title weakens identification.
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?
Lists required inputs (XML, filename, deployment name) but provides no guidance on when to use this tool versus `deployment_create` or `decision_deploy`, nor prerequisites like authentication or permissions needed for deployment.
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. While it mentions the operation applies to 'failed or completed' instances, it fails to disclose synchronous vs asynchronous behavior, side effects (whether new instances are created vs state modified), idempotency, or return values. The mention of 'from a given activity' hints at required parameters not visible in the empty 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 with zero waste. The first sentence states the core purpose, and the second provides the usage context. Efficiently structured and appropriately front-loaded.
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 this is a complex mutation operation (restarting process instances) with an empty input schema, no output schema, and no annotations, the description is insufficient. It should explain expected request body structure (implied by 'activity'), synchronous behavior, and response format to be 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?
Zero parameters present (schema is empty), which normally warrants a baseline of 4. However, the description references 'a given activity', implying parameters (likely activityId or request body) exist that are undocumented in the schema. This partial hint without full specification creates confusion rather than clarity, warranting a deduction.
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?
Clear verb 'Restart' and resource 'process instances' with scope 'for a process definition'. The second sentence adds specificity about re-executing 'from a given activity'. However, it fails to explicitly distinguish from the sibling tool 'processDefinition_restartInstancesAsync', which is critical for selection.
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?
Provides positive use case ('Use to re-execute failed or completed instances') but lacks negative constraints (when NOT to use) and fails to reference the async alternative sibling for long-running operations. No guidance on choosing between sync and async variants.
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 the tool returns profile info, which is necessary given the lack of output schema. However, omits critical behavioral details like pagination, result limits, or permissions required, bearing full burden since no annotations exist.
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 well-structured sentences with no wasted words. Information is front-loaded with the action (Query) and resource (Operaton users) in the first sentence.
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?
While it mentions return values (helpful without output schema), it fails to address the parameter discrepancy or explain pagination behavior essential for a list operation. Incomplete given the schema/annotation poverty.
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?
Description mentions query capabilities by id, firstName, lastName, email, and group membership, but the input schema has zero parameters according to context signals. This creates a misleading mismatch between described functionality and actual schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool queries Operaton users and returns profile information. Distinguishes from sibling `user_getProfile` by implying a search/list operation ('each matching account') rather than a single lookup.
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?
Provides no guidance on when to use this versus `user_getProfile` or other user-related tools. No mention of prerequisites or filtering behavior despite implying query capabilities.
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 full burden and partially succeeds by disclosing the side effect (task assignment eligibility). However, it omits critical operational details: whether the operation is idempotent, what happens if the user is already a member, error conditions, or authorization requirements.
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 with zero waste: the first states the operation and identifiers, the second explains the business consequence. Every element earns its place and is appropriately front-loaded.
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?
As a mutation tool with no annotations and no output schema, the description should provide comprehensive safety and contract details. It explains the business logic but leaves critical technical boundaries undefined, particularly regarding the missing parameter definitions and error handling.
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?
While the description mentions 'user ID and group ID,' the input schema defines zero properties (empty object). This creates a serious mismatch—the description references parameters the schema doesn't allow, confusing how to actually invoke the tool. The baseline for 0 params is 4, but this contradiction significantly reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Add), resource (user to group), and required identifiers (user ID and group ID), distinguishing it from sibling tools like group_removeMember and group_create. However, the mismatch with the empty input schema creates slight ambiguity about where these IDs come from.
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 downstream effect (user receives task assignments) which provides implicit usage context, but fails to explicitly state when to use this tool versus alternatives like group_removeMember, or prerequisites such as group/user existence.
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?
Lacks annotations, so description must carry full burden. Mentions both suspension and resumption, but does not disclose side effects, required permissions, or reversibility details. The reference to a non-existent parameter reduces confidence in the behavioral description.
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, appropriately brief and front-loaded with the primary action. However, the second sentence is wasted describing a phantom parameter, slightly reducing the value of the limited space.
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 state-toggle tool, mentioning both suspend and resume actions. However, lacks information about return values, error conditions, or the actual parameter structure due to the empty schema and missing output schema.
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?
Input schema has 0 parameters (baseline 4), but the description incorrectly references an 'includeJobs' parameter that is not defined in the schema. This creates a mismatch between documented and actual interface, misleading the agent about required inputs.
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?
States a clear action (suspend/resume) and target resource (all jobs for a job definition). Implicitly distinguishes from sibling 'job_setSuspension' (individual jobs) and 'processInstance_setSuspension' via the resource name in the function title.
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?
Attempts to provide usage guidance regarding 'includeJobs=true', but this parameter does not exist in the empty input schema, creating confusion. Fails to explicitly compare against alternatives like 'job_setSuspension'.
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 of behavioral disclosure. It documents the return fields (id, type, retries, dueDate, exceptionMessage) which compensates for the missing output schema. However, it omits critical list-operation behaviors: pagination, result limits, and whether this reads runtime or historic jobs. The 'List' verb implies read-only, but this is not explicitly confirmed.
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 tightly written sentences with no wasted words. The first establishes the operation and filters; the second documents return values. Information is front-loaded with the verb and resource.
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?
While the return fields are documented (helpful given no output schema), the description lacks essential context for a list tool: pagination behavior, maximum results, and the distinction between runtime and historical job queries. Given the presence of history_listJobLogs in siblings, clarifying this scope would be necessary for completeness.
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?
There is a significant discrepancy: the description details 'optional filters' (process instance, job definition, etc.), but the input schema is completely empty (properties: {}). This mismatch could mislead the agent into attempting to provide filter parameters that the schema does not support, potentially causing invocation errors or hallucinated arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('List jobs') and the resource, and distinguishes this from sibling tools like job_get (singular retrieval) by emphasizing the list operation with filtering capabilities. It effectively conveys that this tool retrieves multiple job records.
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 fails to clarify when to use this tool versus siblings like job_get (for single job retrieval), job_count (for aggregation), or history_listJobLogs (for historical vs runtime jobs). No guidance is provided on when filtering is necessary versus retrieving all jobs.
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, description carries full burden. It successfully discloses return value structure (auto-mapped instructions and unmapped activities list) compensating for missing output schema. However, it fails to clarify if this creates a persistent plan object (with side effects) or performs a transient calculation, omitting persistence and idempotency 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 efficient sentences: first establishes action and scope, second details return value. No redundancy or filler 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?
Given empty input schema and no annotations, the description partially compensates by detailing the output structure. However, it lacks critical workflow context (relationship to validation/execution steps) and leaves ambiguity about whether the generated plan is persisted or transient.
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?
While 0 parameters typically warrants a baseline 4, the description creates confusion by referencing 'source' and 'target' process definitions as if they are inputs, yet the schema defines zero properties. This mismatch implies parameters exist where they do not, misleading an agent attempting to populate arguments.
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?
Clear verb ('Generate') and resource ('migration plan'). Specifies it involves 'source to target process definition' and distinguishes output components (auto-mapped vs unmapped activities), giving specific scope. Does not explicitly differentiate from sibling migration_validatePlan or migration_executeBatch.
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 versus alternatives (e.g., when to call validatePlan afterward), no prerequisites mentioned, and no indication that this is typically the first step in a multi-step migration workflow.
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 of behavioral disclosure. It partially succeeds by itemizing the return fields (id, definitionKey, state, business key) since no output schema exists, but fails to mention pagination behavior, result limits, or authentication requirements.
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, efficiently structured sentence with no obvious redundancy. However, the mention of non-existent filters wastes the agent's attention and creates cognitive load regarding phantom input requirements.
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 compensates somewhat for the lack of output schema by listing return fields. However, given the empty input schema, zero annotations, and the discrepancy regarding filters, the description fails to fully prepare the agent for actual invocation constraints.
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 contains zero parameters (100% coverage of null), which should baseline at 4. However, the description incorrectly lists multiple optional filters (business key, definition key/id, state, etc.) that do not exist in the schema. This invents parameters that the agent cannot actually provide, creating confusion about the tool's interface.
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 'List' and resource 'active process instances', establishing the core function. While it mentions specific filters (business key, definition key/id, etc.), the fundamental purpose is unambiguous despite this schema mismatch.
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 word 'active' implies a scope distinction from the sibling 'history_listProcessInstances', suggesting when to use this tool versus historical queries. However, it lacks explicit guidance on choosing between this and 'processInstance_count' or 'processInstance_get'.
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 the full burden of behavioral disclosure. It fails to indicate whether this is a read-only operation, its performance characteristics, or what the return value contains. The mention of unsupported filters further reduces 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 appropriately concise with three short sentences that are front-loaded with the primary action. Each sentence serves a distinct purpose (action, capability, use case), though the middle sentence creates confusion given the schema constraints.
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 counting utility, the description covers the essential 'what' and 'why'. However, the lack of output schema combined with the mismatch between described filters and actual schema parameters leaves critical invocation details ambiguous.
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 contains zero parameters, which by the evaluation guidelines establishes a baseline score of 4. The description's reference to 'filter criteria' is misleading given the empty schema, but with no parameters to document, the semantic requirement is technically minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action (counting user tasks) clearly, but becomes problematic by claiming the tool accepts 'filter criteria' when the input schema defines zero parameters. This creates ambiguity about whether the tool actually supports filtering or if the schema is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for workload sizing' provides contextual usage guidance. It also references 'task list' implying this is an alternative for counting versus listing, but lacks explicit guidance on when to prefer this over fetching the full task list.
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 and description fails to disclose return type format (integer/object?), idempotency, or error conditions. The 'filter criteria' claim without schema parameters creates behavioral uncertainty.
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?
Optimal two-sentence structure with zero waste. Front-loaded action verb and efficient cross-reference to sibling tool avoids redundant filter documentation.
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?
Critical gaps remain: no return value specification (scalar vs object), no resolution of the filter/schema mismatch, and no safety annotations. For a computational endpoint without output schema, the description fails to specify what constitutes a successful response.
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 zero parameters in schema (baseline 4), the description attempts to add value by referencing deployment_list for filter definitions. However, the empty schema contradicts this guidance, creating implementation confusion despite the semantic intent.
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?
Clearly states the tool counts deployments using specific verb and resource. The mention of 'filter criteria' distinguishes it from retrieval operations, though this creates confusion given the empty input schema showing no parameters.
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?
References deployment_list to indicate filter parity, implicitly suggesting use when only cardinality is needed versus full listing. Lacks explicit guidance on when to prefer count over list, or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. The verbs 'List' and 'Returns' imply a read-only, non-destructive operation, but the description never explicitly confirms safety, idempotency, or side effects. It provides no information on pagination, rate limits, or authentication requirements.
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?
Three well-structured sentences with logical flow: action statement, filter capabilities, and return value specification. Each sentence earns its place by conveying distinct information, though the second sentence describes non-existent parameters which reduces its value.
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?
Without an output schema, the description usefully specifies return fields (ID, name, time). However, it omits safety confirmations (destructive vs read-only) and, most critically, references filter parameters absent from the schema, leaving the actual interface ambiguous. For a listing tool with no annotations or output schema, more comprehensive behavioral context was needed.
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 defines zero parameters (empty properties object), yet the description explicitly references filter parameters: 'name, source, deployment time range, or tenant.' This creates a critical mismatch where the description claims functionality (filtering) that the schema does not support, likely confusing the agent about what inputs are actually accepted.
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 specific action (List) and resource (deployments in the engine). It implicitly distinguishes from siblings like 'deployment_count' (aggregation) and 'deployment_listResources' (sub-resources) through the resource naming, though it could explicitly clarify when to prefer this over 'deployment_getById' for specific lookups.
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 by listing available filter criteria (name, source, time range, tenant), suggesting when the tool is appropriate. However, it lacks explicit 'when-not-to-use' guidance or alternatives for cases requiring specific ID lookups (use deployment_getById) or simple counts (use deployment_count).
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 disclosure burden. While it lists resource types, it omits safety confirmation (is this read-only?), error behavior (what if ID is invalid?), pagination limits, and whether returned resources contain metadata or full content.
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 efficient sentence front-loaded with the action verb 'List'. Every clause earns its place: resource types are enumerated specifically, and the scope (by deployment ID) is clearly stated. Zero 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 no annotations and no output schema, the description adequately covers the operation's intent but lacks critical implementation context like return value structure or error conditions. For a resource-listing tool, mentioning the output format (array of resource objects) would significantly improve 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?
Input schema has 0 parameters (empty properties object), which per rubric establishes a baseline of 4. The description mentions 'by deployment ID' which implies a filtering parameter, but since the schema is empty, this creates ambiguity about how the ID is provided (likely via path, but not clarified).
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 (List), resource (resources/BPMN/DMN/forms), and scope (by deployment ID). It implicitly distinguishes from sibling 'deployment_list' (which lists deployments) by specifying 'resources... included in a deployment', though it could explicitly contrast with 'deployment_getById'.
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 siblings like 'deployment_getById' or prerequisites (e.g., obtaining the deployment ID from 'deployment_list' first). The phrase 'by deployment ID' implies a dependency but doesn't clarify the workflow.
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 disclosure burden. Only states that it 'Returns group details' but omits safety profile (read-only), pagination behavior, default result limits, or error conditions. Minimal behavioral context for a data retrieval 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 efficient sentences with no redundancy. First sentence defines query capabilities, second defines return value. 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?
Adequate for a zero-parameter list operation but lacks output schema details or explanation of what 'group details' includes. No pagination or result set size guidance. Sufficient but minimal for the tool's apparent complexity.
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?
Input schema has zero parameters (baseline 4 per rubric). Description adds value by enumerating the intended filter dimensions (id, name, type, member user ID) that would logically be query parameters, providing semantic context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Query' and resource 'Operaton groups' clearly. Distinguishes from sibling mutation tools (group_create, group_delete, group_addMember) by describing a read/search operation. However, slightly weakened by claiming filters (id, name, type, member user ID) while the schema shows zero parameters.
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?
Provides no explicit guidance on when to use versus alternatives. No mention of prerequisites, permissions, or when to prefer specific group lookups over listing. Fails to clarify relationship to other group operations.
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 the return value structure (total count and per-batch breakdown) which is necessary given the lack of output schema, but fails to clarify critical behavioral aspects: whether this triggers immediate execution or just resets counters, idempotency characteristics, or error handling when no failed jobs exist.
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 two-sentence structure efficiently communicates the action and return value without redundancy. However, the failure to address the empty parameter schema in relation to the batch scope represents a missed opportunity to prevent invocation errors.
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?
Adequately covers the core operation for a batch mutation tool but leaves significant gaps: it does not explain the batch selection mechanism (critical given zero parameters), side effects, or how this coordinates with migration_getBatchFailures. Given the tool complexity and lack of annotations, more behavioral context is needed.
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 zero parameters, the baseline score is 4. However, the description mentions operation occurs 'in one or more batches' without clarifying that batches are automatically discovered rather than specified via parameters, creating potential confusion about whether parameter input is required.
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?
Clearly identifies the specific action (reset retries) and target resource (failed migration jobs in batches), distinguishing it from generic job tools like job_setRetries through its batch-oriented scope. Falls short of a 5 because it does not explicitly contrast with sibling migration tools or clarify the implicit batch selection mechanism.
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?
Provides no guidance on when to use this tool versus alternatives like job_setRetries or migration_resumeBatch, nor does it mention prerequisites such as checking batch status or failures first. The workflow context is completely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It clarifies that the tool creates a new deployment (mutation behavior) rather than modifying the existing one, which is valuable. However, it fails to disclose side effects like whether the previous deployment remains active, whether running instances are migrated, or if the operation is idempotent.
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 consists of two efficient sentences with no redundant words. Every sentence earns its place: the first defines the action and scope, the second explains the underlying mechanism (creating from previous resources). Appropriately front-loaded and 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?
Given the empty input schema and lack of annotations or output schema, the description provides the basic conceptual model (redeploy creates new from old). However, with zero parameters, it fails to explain how to identify which deployment to redeploy—a critical gap that leaves the tool practically unusable without additional 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?
The schema has 0 parameters (baseline 4), but the description mentions 'optionally selecting specific resources,' which implies the existence of parameters for resource selection that are not present in the schema. This creates confusion about how to specify which resources to include or exclude, making the description misleading regarding the tool's actual interface.
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 'Redeploy[s] an existing deployment' and distinguishes it from sibling tools like deployment_create by specifying it 'Creates a new deployment from resources of a previous deployment.' However, it could be clearer about whether this updates the existing deployment in-place or creates a copy.
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 by mentioning 'from resources of a previous deployment,' suggesting use when you want to reuse existing deployment resources rather than create from scratch. However, it lacks explicit guidance on when to use this versus deployment_create or deployment_update (if it existed), and doesn't mention prerequisites like needing a valid deployment ID.
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 return payload structure (variable name, type, value, activity instance) which partially compensates for missing output schema. Lacks essential behavioral details expected when no annotations present: read-only safety, pagination behavior, result limits, or performance characteristics of history queries.
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 information-dense sentences with efficient structure. First sentence establishes functionality and filters; second describes return values. No filler content, though front-loading could emphasize the read-only nature given missing annotations.
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 coverage of return values given no output schema exists, but incomplete for a history query tool: missing pagination controls, maximum result limits, sorting options, and explicit safety guarantees that annotations would normally provide.
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?
Provides semantic meaning for filtering criteria (process instance ID, variable name) that compensate for the completely empty input schema. Baseline 4 maintained for zero-parameter tools, though the description references parameters not formally declared in the schema structure.
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?
Clear verb (Query) and resource (historic variable instances) with specific filters mentioned (process instance ID, variable name). Distinguishes from siblings by specifying 'historic' scope, though could better contrast with runtime variable tools like processInstance_getVariables.
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 versus runtime variable retrieval (processInstance_getVariables) or other history query tools. The 'historic' qualifier provides only implicit context without specifying use cases involving completed versus active process instances.
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 disclosure. It compensates for the missing output schema by listing return fields (operatorId, timestamp, operationType) and implies read-only behavior via 'Query'. However, it omits pagination behavior, authorization requirements, and the return structure (array vs object).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences. It is front-loaded with the action, documents outputs in the second sentence, and mentions filtering in the third. Every sentence serves a purpose, though the filter mention creates slight ambiguity given the empty schema.
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 no output schema, the description adequately compensates by documenting return fields. However, it should explicitly differentiate from history_listUserOperations and clarify whether the mentioned filters are query parameters (despite empty schema) or conceptual constraints. It meets minimum viability but has clear gaps for a complex BPM domain 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?
With zero parameters and 100% schema coverage (trivially), the baseline score of 4 applies. The description mentions 'Filters: processDefinitionKey, date range' which confusingly implies parameters that do not exist in the empty input schema, though this could be interpreted as behavioral context rather than input documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Query') and identifies the resource ('Operaton user operation log') and scope ('migration audit entries'). It implicitly distinguishes from sibling history_listUserOperations by specifying 'migration' audit entries, though it doesn't explicitly name the alternative.
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 states what the tool returns but provides no guidance on when to use this tool versus the sibling history_listUserOperations, or versus other migration tools like migration_listBatches. No prerequisites or exclusions are mentioned.
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, requiring description to carry full behavioral disclosure burden. It explains return structure categories and optional variable-checking logic. However, lacks safety profile disclosure (read-only vs. side effects), error handling specifics, or performance characteristics for the comparison 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 efficient sentences front-load critical information: first defines core comparison and return types, second covers optional variable-checking behavior. No redundant text or filler despite being description-only with no title.
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?
Absence of output schema is partially mitigated by description detailing return categories (auto-mappable pairs, unmapped, new). However, critical incompleteness: empty input schema combined with description's reference to 'supplied instance IDs' leaves invocation context ambiguous. Does not explain how source/target process definitions are identified given zero schema properties.
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?
Baseline for 0 parameters is typically 4, but description confusingly references 'supplied instance IDs' implying input parameters exist, while schema is strictly empty. This creates ambiguity about how source/target definitions and optional instance IDs are specified, failing to clarify the empty schema interface.
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?
States specific comparison operation ("Compare source and target process definition activities") and enumerates return categories (auto-mappable pairs, unmapped source activities, new target activities). Distinguishes from sibling migration execution tools (e.g., migration_executeBatch) by focusing on analysis/candidate identification, though could explicitly clarify this precedes actual migration.
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 when-to-use or when-not-to-use guidance relative to migration_* siblings (e.g., migration_generatePlan, migration_validatePlan). Does not specify prerequisites for providing source/target definitions despite empty input schema. User must infer appropriate context solely from the tool name.
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 discloses return fields (key, id, version, deployment info) which provides some transparency about output structure. However, it omits other critical behavioral traits like read-only safety, pagination behavior, or rate limiting that would help an agent understand operational constraints.
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 in three clauses: purpose ('List...'), capabilities ('Filter by...'), and output ('Returns...'). Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description partially compensates by listing return fields. However, it omits pagination details, sorting options, and whether filters are optional or required, leaving gaps in contextual completeness for a listing operation.
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?
Despite the empty input schema (0 params), the description mentions five filter criteria (key, name, version, category, tenant), attempting to add semantic meaning. However, this creates ambiguity since the schema contradicts these capabilities by defining no parameters, creating potential confusion about how to invoke filtering.
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 'List' and resource 'deployed process definitions', distinguishing it from siblings like 'processInstance_list' (instances vs definitions) and 'deployment_list' (deployments vs definitions). However, it stops short of explicitly contrasting with single-retrieval siblings like 'processDefinition_getById'.
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?
While it mentions filtering capabilities, it provides no explicit guidance on when to use this bulk listing versus single-definition siblings like 'processDefinition_getByKey', nor does it mention prerequisites or typical 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 carries the full burden of behavioral disclosure. While it explains the domain concept (DRDs as dependencies between decision tables), it provides no operational details such as pagination behavior, maximum result limits, sorting options, or what fields are returned in the response. A list operation with zero parameters should ideally clarify if it returns all items unfiltered.
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 consists of two highly efficient sentences with zero waste. The first sentence states the action and resource (List deployed DRDs), and the second provides essential domain context defining what DRDs represent. 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?
Given zero parameters and a simple list operation, the description adequately covers the essential domain context by explaining what DRDs are. However, without an output schema, it should ideally describe the return structure (e.g., that it returns metadata about deployed definitions) or mention that results are unfiltered. It meets minimum requirements but leaves operational 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?
The input schema contains zero parameters. According to scoring guidelines, this establishes a baseline of 4. The description does not need to compensate for missing schema documentation, though it could have explicitly noted that no filtering is available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a specific resource ('deployed Decision Requirements Definitions') and clarifies the domain concept (DRDs as dependencies between decision tables). This implicitly distinguishes it from sibling 'decision_list' by clarifying that DRDs represent the dependency structure between tables, not the tables themselves, though it does not explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by explaining that DRDs describe 'dependencies between decision tables.' This suggests the tool should be used when examining relationships/structure in a DMN model versus retrieving individual decision tables (presumably handled by 'decision_list'). However, it lacks explicit 'when to use' language or direct comparison to 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, so description carries full disclosure burden. It effectively describes the return payload structure (actor, action, target, timestamp) and specific operation types monitored. However, lacks safety/performance context (e.g., time range limits, default windowing, or pagination behavior) that would help an agent understand operational constraints.
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, zero waste. First sentence establishes function; second details return structure with parenthetical specifics. Every clause earns its place without repetition of structured metadata.
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 zero-parameter query tool: explains intent and return structure. However, given the dense sibling namespace (6 history_list* variants), description should clarify scope boundaries—specifically that this tracks user-initiated operations (claims, completes) versus system-generated history events.
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?
Input schema contains zero parameters, which per guidelines establishes a baseline of 4. Description neither adds nor subtracts from this baseline since there are no parameters to document.
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?
States specific verb (Query) and resource (user operation audit log). Lists concrete operation types tracked (claim, complete, delete) which helps distinguish from sibling history_list* tools that track different entities (ActivityInstances, ProcessInstances, etc.). Could explicitly clarify 'user operations' context relative to task management vs other history scopes.
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?
Provides no guidance on when to invoke this vs alternatives like history_listTaskInstances or history_listProcessInstances. No mention of audit granularity (e.g., 'use for tracking manual task assignments vs automatic process events').
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 burden of disclosing return structure and fields (type, message, cause, root cause, process definition ID, activity ID), which it does. However, it lacks other behavioral details like error handling (e.g., 404 if ID not found), idempotency, or authentication requirements.
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 with no waste. The first sentence front-loads the action and resource; the second documents return values. 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?
The description compensates for the missing output schema by listing return fields. However, given the schema defines zero parameters despite the 'by ID' reference, the description fails to fully resolve how to provide the ID (path vs. query vs. body), leaving a critical gap for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), but the description mentions 'by ID,' implying the required parameter that the schema fails to define. This adds crucial semantic information. With zero parameters, the baseline is 4, and the description provides the minimal necessary hint about the ID requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Retrieve), resource (incident), and scope (single by ID), which distinguishes it from siblings like incident_list or incident_count. However, it does not clarify whether this targets active vs. historical incidents (relevant given history_listIncidents exists).
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 incident_list, history_listIncidents, or incident_resolve. The description only states what it does, not under what circumstances to invoke 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 full burden. It discloses return content (activity details, process definition, suspension state) which substitutes for missing output schema. However, it lacks disclosure on safety (read-only nature), side effects, or permissions despite the mutation-sounding siblings present.
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 efficient sentences with zero waste. Front-loaded with the action verb 'Retrieve'. First sentence defines the operation, second defines the return payload—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 retrieval tool with no output schema, the description adequately covers return values. However, gaps remain: no mention of where to source the ID (prerequisite from jobDefinition_list), and the discrepancy between 'by ID' text and empty input schema leaves invocation context incomplete.
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?
Input schema has zero parameters, triggering baseline score of 4. However, note that the description mentions 'by ID' while the schema is empty, which could confuse invocation but does not lower the semantic score under the rubric.
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?
Clear verb (Retrieve), resource (job definition), and scope (single by ID). Distinguishes from siblings jobDefinition_list (plural) and jobDefinition_setSuspension (modification) through explicit scope, though it does not explicitly name these alternatives.
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?
States what data is returned (activity details, process definition, suspension state), implying when to use it, but provides no explicit guidance on when to use this versus jobDefinition_list or how to obtain the required ID.
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 of behavioral disclosure. It identifies the destructive nature ('delete') and response format, but omits critical safety details for a deletion operation: whether cancellation is irreversible, effects on in-progress migrations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with zero waste. The first sentence front-loads the action and scope, while the second addresses the return behavior. 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?
Given this is a destructive operation with no annotations, empty input schema, and no output schema, the description is minimally sufficient but lacks necessary safety warnings, side-effect documentation, or details on batch state requirements (e.g., can you delete running batches?).
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 parameters (baseline 4). The description adds the crucial semantic context that the operation targets specific resources 'by ID', which the empty schema does not convey. This is the only indication of how to specify which batches to delete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Cancel', 'delete') and identifies the resource ('migration batches') clearly. However, it does not distinguish this tool from siblings like 'migration_suspendBatch' or 'migration_resumeBatch', leaving ambiguity about when to choose destructive cancellation over suspension.
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 the return value ('Returns per-batch success or error') but provides no guidance on when to use this tool versus alternatives like suspendBatch, nor does it mention prerequisites such as requiring batch IDs from migration_listBatches before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It partially discloses behavior by listing the specific status fields returned (totalJobs, jobsCreated, jobsCompleted, jobsFailed, suspended), which hints at the output structure. However, it lacks information about error handling (e.g., batch not found), performance characteristics, or whether the operation is read-only (implied by 'Get' but not stated).
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, efficient sentence that front-loads the purpose ('Get current status') and appends the specific field details. Every word earns its place with no redundancy or boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema provided, the description partially compensates by enumerating the returned fields. However, given the empty input schema (0 properties), the description fails to explain how to identify which specific batch to query—an essential gap for a tool targeting a 'single' resource.
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 contains 0 parameters, which triggers the baseline score of 4 per evaluation rules. With no parameters to describe, there is no additional semantic information needed beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('status of a single migration batch') and enumerates the specific fields returned (totalJobs, jobsCreated, etc.), which helps distinguish it from sibling list operations. However, it does not explicitly differentiate from 'migration_getBatchSummary' or 'migration_getBatchFailures', leaving some ambiguity about which status tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'migration_getBatchSummary' or 'migration_getBatchFailures', nor does it mention prerequisites or conditions for use. The agent is given no signal for tool selection strategy.
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 disclosure burden. It effectively establishes the aggregate scope ('across all deployed definitions') and specific metrics, but omits critical behavioral traits: it doesn't confirm the operation is read-only/safe, doesn't mention pagination for large deployments, and doesn't describe the response structure (array vs object).
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 efficient sentence uses a colon structure to front-load the action ('Get process definition statistics') and append specific details. No wasted words; every phrase earns its place by defining scope or return 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 zero parameters, no annotations, and no output schema, the description adequately covers invocation context by specifying exactly which statistics are returned (instances, failed jobs, incidents). However, lacking output schema, it could have briefly indicated the return format (e.g., 'returns array of statistics').
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 contains zero parameters, so by rule baseline is 4. The description appropriately implies no filtering is possible by stating statistics are gathered 'across all deployed definitions' without parameter qualification.
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 specifies the resource ('process definition statistics'), scope ('across all deployed definitions'), and exact metrics returned ('instance counts, failed job counts, and incident counts'), which distinguishes it from siblings like processDefinition_activityStats (activity-level) and processDefinition_count (simple counting). However, it uses the generic verb 'Get' rather than a more specific verb like 'Aggregate' or 'Calculate', and doesn't explicitly contrast with 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 guidance on when to use this tool versus alternatives like processDefinition_activityStats (for activity-level statistics) or incident_list (for detailed incident data). No prerequisites, filters, or 'when-not-to-use' conditions are mentioned.
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 of behavioral disclosure. It compensates well for the missing output schema by documenting the specific returned fields (firstName, lastName, email), but omits error handling details (e.g., what happens if the user is not found), authentication requirements, or explicit confirmation that this is a safe read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two efficient sentences with no waste: the first states the action and target, the second documents the return payload. Information is front-loaded appropriately.
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 (zero parameters, no nested objects) and lack of output schema, the description adequately covers the essential information by listing the specific profile fields returned. It appropriately delegates the 'retrieve' semantics to the tool name while expanding on the data payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the input schema, the baseline score is 4 per rubric guidelines. The description mentions 'by ID' which implies parameter requirements, but since the schema is definitively empty, no additional parameter semantics are needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Retrieve') and identifies the resource ('Operaton user' profile) and specific return fields. However, it mentions 'by ID' while the input schema contains zero parameters, which creates confusion about how the user is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like user_list (which likely returns multiple users) or user_updateProfile. It does not mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clarifies scope (includes resolved incidents) and filtering capability, but omits pagination behavior, rate limits, and return structure 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?
Three efficient sentences front-loaded with the core action. Every sentence serves a distinct purpose: capability declaration, filter enumeration, and usage context. No redundant words or tautology.
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 query tool with no annotations or output schema, covering primary functionality and filters. However, lacks details on response format, pagination, or specific distinction from the many sibling tools in this large API surface.
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?
Input schema is empty (0 params), earning baseline 4. The description adds significant value by enumerating specific filter dimensions (process instance, type, resolution state) not present in the schema structure.
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?
Clear verb 'Query' and resource 'historic incidents' with scope 'including resolved ones', distinguishing it from active incident tools. However, it doesn't explicitly differentiate from sibling tool incident_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context with 'Use for post-incident analysis' but lacks explicit guidance on when to prefer this over incident_list or other history tools, and includes no exclusion criteria.
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 successfully explains the semantic meaning of incidents (failed jobs, scripts, custom conditions) and implies a read-only operation via the 'List' verb, but does not address return format, pagination, or safety guarantees.
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?
Three well-structured sentences that are front-loaded with the primary action and contain no redundant information. Each sentence earns its place by conveying distinct information (action, filtering scope, and semantic definition).
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 (no parameters, no output schema required per rubric), the description adequately covers essential operational context. It sufficiently explains what the tool retrieves and the nature of the incidents without needing to elaborate on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters defined in the input schema, the baseline score applies. The description mentions filtering dimensions (type, message, process definition, activity), which provides context for what the tool handles, even though the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List active incidents in the engine'), clearly distinguishing this from the sibling history_listIncidents tool by specifying 'active' incidents. It also clarifies what constitutes an incident (failed jobs, scripts, or custom conditions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes this tool from historical querying by emphasizing 'active' incidents, and mentions filtering capabilities, but lacks explicit guidance on when to use this versus incident_getById or incident_resolve.
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 return contents (value, type, scope) and scope constraint (active instances only), but omits error behaviors, side effects, and whether this is read-only (implied but not confirmed).
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 efficient sentences with no redundancy: first states action, second states return value. Well-structured and appropriately sized.
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?
Adequately covers basic intent given no output schema exists, mentioning return structure elements. However, lacks error handling details and doesn't resolve the parameter/schema mismatch.
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 0 parameters, but description implies required inputs (instance identifier, variable name) are needed to retrieve a 'single named variable'. Description fails to bridge this gap or explain the discrepancy, leaving the agent confused about how to specify the target.
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 specific verb 'Retrieve', identifies resource as 'single named variable' from 'active process instance', and implicitly distinguishes from siblings like processInstance_getVariables (plural) and history_listVariableInstances (active vs historic).
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 distinction from batch/variable retrieval tools via 'single' keyword, but lacks explicit guidance on when to prefer this over processInstance_getVariables or history_listVariableInstances, and doesn't mention error scenarios.
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 disclosure burden. It explains the behavioral consequence of suspension (instances cannot advance) and implies reversibility. However, missing safety disclosures typical for mutation operations: no mention of idempotency, required permissions, or what happens to active tasks/jobs.
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 tightly constructed sentences with zero waste. First states purpose, second gives specific parameter instructions, third explains behavioral constraint. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a toggle operation but gaps remain given zero annotations and no output schema. Missing: return value description (likely empty or instance data), error cases (invalid ID, already suspended), and authorization requirements. Could also clarify relationship to job suspension.
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 has 0 parameters (baseline 4). Description compensates by clarifying the implied toggle parameter semantics: 'suspended=true to pause' and 'suspended=false to resume,' adding meaning that a bare boolean schema would not convey. Mentions 'by ID' indicating the targeting parameter.
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?
Clear verb ('Suspend or resume') and resource ('process instance by ID'), distinguishing it from siblings like processDefinition_suspendByKey or job_setSuspension. The 'by ID' qualifier helps clarify this targets specific instances rather than batches or definitions.
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?
Explains the toggle mechanism (suspended=true/false) and effect ('cannot advance until resumed'), providing implicit guidance on when to use. However, lacks explicit comparison to alternatives like canceling or deleting instances, and doesn't mention prerequisites such as requiring the instance ID.
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 return value type ('task metadata') and audience ('operator review'), but fails to state the read-only nature, pagination behavior, or potential rate limits typical for list operations in BPM systems.
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 optimally concise with two sentences: the first front-loaded with the action and filtering capabilities, the second clarifying the return value. No redundant words or tautologies.
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 high complexity of the BPM domain (80+ sibling tools) and empty input/output schemas, the description provides minimal viable context by listing filterable fields. However, it lacks critical details like pagination mechanisms, sorting options, or the structure of the returned task metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds significant value by enumerating available filtering dimensions (assignee, candidate group, process instance, variables, due date) that compensate for the empty input schema, effectively documenting what would otherwise be undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Query user tasks' with a specific verb and resource, distinguishing it from mutation siblings like task_create or task_complete. However, it does not explicitly differentiate from similar query siblings like task_count or task_getById.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for operator review' provides implied context about the intended user role, but lacks explicit guidance on when to use this versus task_getById (single task retrieval) or task_count (aggregation). No alternatives or prerequisites are mentioned.
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 compensates for missing output schema by listing specific return fields (name, source, time, tenant ID), which is valuable. However, it fails to disclose error behaviors (e.g., ID not found), safety characteristics, or idempotency.
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 with zero waste. First sentence establishes purpose, second documents return values. Appropriately front-loaded and sized 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?
For a simple retrieval tool, description adequately covers return values (compensating for no output schema), but lacks error handling details and does not clarify how the ID is provided given the empty input schema. Meets minimum viable completeness but has clear 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?
Zero parameters in input schema establishes baseline of 4 per scoring guidelines. Description references 'by its ID' explaining the retrieval method, though note the schema appears incomplete as it lacks the ID parameter entirely.
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 provides specific verb (Retrieve), resource (deployment), and scope (by its ID). This clearly distinguishes from sibling deployment_list (plural/all) and deployment_create/deployment_delete (mutations).
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 provided on when to use this specific tool versus deployment_list or other retrieval alternatives. No mention of prerequisites (e.g., needing the ID beforehand) or error 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?
No annotations provided, so description carries full burden. Adds valuable domain context (authorization/task assignments) beyond what structured fields provide. Missing: side effects, error conditions (e.g., duplicate ID handling), persistence guarantees, or return value structure for the creation 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 efficient sentences with zero redundancy. Front-loaded with the operative verb. Second sentence provides domain context without waste. Appropriate length for tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for apparent low complexity (0 schema properties). Description hints at required fields (id, name) that the schema omits, and explains business purpose. Lacks output description, but given no output schema exists, this is acceptable. Could mention if creation is idempotent or destructive.
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?
Input schema has 0 properties, so baseline 4 applies. Description implicitly documents expected entity fields ('id, name, and optional type'), compensating for the empty schema by indicating what data the tool consumes/expects despite the lack of formal parameter definitions.
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?
Specific verb 'Create' + resource 'Operaton group' clearly identifies the action. Distinguishes from sibling tools like group_list (read) and group_delete (remove). Mentions key attributes (id, name, type) providing scope. Minor gap: 'Operaton' assumes domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context ('Groups are used to manage candidate task assignments and authorization') explaining functional purpose. However, lacks explicit 'when to use' guidance, prerequisites (e.g., admin permissions), or differentiation from user_create for authorization tasks.
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 specific error behavior ('not-found error if the group does not exist') and success behavior ('Returns confirmation'), which compensates partially for missing annotations. However, lacks disclosure on destructive permanence, cascade effects on group memberships, or authorization requirements given the destructive nature and absence of destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. Front-loaded with the core action, followed by precise behavioral outcomes. Every sentence earns its place by conveying distinct information (purpose, success case, error case).
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 basic operational contract (success/error) but insufficient for a destructive operation with no annotations. Missing critical safety context such as whether deletion is permanent, whether members are cascade-deleted or orphaned, and required permissions.
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?
Input schema has zero parameters, which normally warrants baseline 4. The description adds crucial context by specifying 'by ID', indicating the group identifier is required (likely as a path parameter not reflected in the body schema), though it does not specify the ID's data type or format.
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 specific verb ('Delete') + resource ('Operaton group') + scope ('by ID'). Distinguishes effectively from siblings like group_create, group_addMember, and group_list by specifying the destructive removal action on the entire group entity.
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?
Provides no guidance on when to use this tool versus alternatives like group_removeMember (which removes a user from a group without deleting the group itself). No prerequisites or conditional usage scenarios are mentioned.
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 return value structure (timestamp, job type, retries, exception details) which is necessary given no output schema. However, lacking operational details like pagination, result limits, or sorting since no annotations are provided to cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second describes return value. No redundant information or 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?
Adequately compensates for missing output schema by describing returned fields. However, as a history query tool with no annotations, it should detail pagination behavior and whether it returns all logs or requires filtering criteria.
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?
Input schema has 0 parameters, establishing baseline 4 per scoring rules. Description references 'process instance' which describes the data domain rather than explicitly defining non-existent input parameters, so no explicit contradiction occurs.
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 specific verb 'Query' with resource 'historic job execution logs' and scope 'for a process instance'. Effectively distinguishes from siblings like job_list (current jobs) and history_listProcessInstances (process instances vs job 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?
No explicit when-to-use guidance, no differentiation from similar history tools (history_listActivityInstances), and no mention of prerequisites like requiring a process instance ID despite the description implying instance-specific querying.
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 disclosure burden. It mentions 'filter criteria' but the input schema has zero parameters, creating ambiguity about how filtering is performed. It lacks disclosure of return format (number vs object), performance characteristics, or whether this is a read-only 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 total. First sentence establishes purpose immediately; second sentence provides usage guidance. No redundant or filler 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?
Given the low complexity (zero parameters, no output schema, no annotations), the description provides adequate workflow context (backlog assessment). However, it should clarify the return value format and resolve the mismatch between 'filter criteria' and the parameter-less schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4, but the mention of 'filter criteria' in the description conflicts with the empty schema (properties: {}), implying parameters exist when they do not. This creates confusion about how to specify filter criteria.
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 specific verb (Count), resource (jobs), and scope (matching filter criteria), clearly distinguishing from siblings like `job_list` (list) and `job_get` (retrieve single).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use to assess backlog size before listing.' This provides workflow context and implicitly references the sibling `job_list` tool, though it doesn't explicitly name the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Adds useful context by listing returned fields and 'post-migration' timing, but omits mutation safety confirmation (implied by 'get' but not stated), error behaviors, or prerequisites. Does not contradict implied read-only 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 efficiently structured sentences. First sentence front-loads function and data points; second provides usage context. Zero filler or redundancy—every word 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?
Compensates well for missing output schema by enumerating aggregate fields in description. Covers timing (post-migration) and purpose (sign-off). Lacking only error-handling guidance and auth/permission notes for full completeness given no annotations or output 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?
Input schema has zero parameters (empty object), establishing baseline 4 per rubric. Description appropriately doesn't invent parameters, though phrase 'across one or more batch IDs' could confuse slightly by implying input criteria when describing output scope; however, no parameter documentation is required given empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Aggregate' with resource 'post-migration summary' and explicit field list (totalSubmitted, succeeded, failed, duration). Distinguishes from siblings like migration_getBatchStatus by emphasizing cross-batch aggregation and sign-off use case, though could more explicitly contrast with single-batch queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides positive usage context ('Suitable for deployment sign-off records') indicating when to use (post-migration validation). Lacks explicit exclusions or named alternatives—doesn't clarify when to use migration_getBatchStatus vs this aggregation 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?
Provides some behavioral context by stating it 'Returns per-batch success or error,' but missing critical details for a batch mutation tool: whether operation is synchronous/async, side effects, what happens if batch isn't suspended, or permission requirements. No annotations provided to cover these gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient: two sentences with zero waste. First sentence covers purpose and target, second covers return value. 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?
Covers basic operation and return value (compensating for missing output schema), but lacks operational details expected for a batch mutation tool: error conditions, batch size limits, state transition prerequisites, or concurrency behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters (baseline 4), but description states 'by ID' implying input parameters that aren't reflected in the empty schema, creating ambiguity about how IDs are passed (path vs body). Description compensates slightly by indicating the 'one or more' cardinality.
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 specific action (Resume), target resource (migration batches), and prerequisite state (suspended), distinguishing it from siblings like migration_suspendBatch or migration_deleteBatch.
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 context by specifying 'suspended' batches and IDs, but lacks explicit guidance on when to choose this over alternatives like migration_executeBatch or migration_awaitBatch, and doesn't mention where to obtain batch IDs.
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 return format ('per-batch success or error') which compensates partially for missing output schema. However, lacks operational details crucial for a mutation: whether suspension is immediate/async, effect on running jobs, or reversibility (despite no annotations to carry this burden).
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 with zero waste: first defines action/target, second specifies return value. Appropriately sized for the 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?
Adequate for basic tool selection but incomplete for a mutation operation: no annotations, no output schema, and missing behavioral context like state transitions or side effects. 'Returns... error' covers minimum return value disclosure.
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?
0 parameters present, triggering baseline score 4 per rubric. Description mentions 'by ID' implying identification mechanism, though schema is empty—this adds context but doesn't fully resolve the parameter documentation 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?
Specific verb ('Suspend') + resource ('migration batches') + scope ('by ID'). Clearly distinguishes from siblings like migration_resumeBatch, migration_deleteBatch, and migration_executeBatch through distinct action semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to suspend vs. delete, prerequisites (e.g., batch must be active), or relationship to migration_resumeBatch. 'By ID' implies need for IDs but doesn't clarify if migration_listBatches should be called 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?
Discloses 'active' scope constraint (excluding historical instances) given no annotations provided. Missing: output format description, readOnly characteristics, performance/cost warnings for large counts, and clarification on how filters work with empty 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?
Three sentences, zero waste. Front-loaded with the core action (Count), followed by capability note (filters), and usage guidance (pagination planning). Every sentence 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?
Adequate for a simple count utility but missing output value description (number? object?). The mismatch between described filters and empty schema creates an information gap that should be resolved with explicit parameter documentation or a pointer to the list tool's schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
References 'filter criteria' and 'Supports same filters as list' to compensate for empty input schema, implying parameters exist and match the list operation. However, fails to explain how filters are passed (e.g., query parameters vs body) or describe any specific filter semantics, leaving ambiguity given the schema contradiction.
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?
States specific verb 'Count' and resource 'process instances', with scope qualifier 'active' distinguishing from history_listProcessInstances sibling. Implies distinction from processInstance_list via 'Supports same filters as list', though could explicitly name the sibling for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use before listing to plan pagination'. References 'list' implying the alternative operation, though does not explicitly name processInstance_list as the alternative or mention when not to use (e.g., when detailed records are needed).
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 full burden. It successfully discloses the non-mutating workflow behavior (stays in same activity state) but omits safety details (permissions, idempotency), side effects (variable updates, history entries), or return value structure.
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 high-density sentences with zero redundancy. First sentence establishes scope via colon-delimited list; second sentence provides critical behavioral guardrail. 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?
Adequate for basic operation given the empty schema and lack of annotations, but gaps remain: no positioning vs field-specific sibling tools, no output contract description, and the described metadata fields have no corresponding schema definitions.
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?
Input schema contains zero parameters (empty properties object), triggering baseline score of 4. The description adds semantic value by listing the six implicit updatable fields, compensating somewhat for the empty schema, though it cannot provide type/format 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?
Excellent specificity: verb 'Update', resource 'metadata of a user task', and explicit enumeration of six editable fields (name, description, assignee, due date, priority, parent task). The clause 'Does not advance the task in the workflow' sharply distinguishes it from the sibling task_complete tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides only negative guidance ('Does not advance'), indicating when NOT to use it vs task_complete. Critically fails to guide selection between this general-purpose updater and sibling-specific tools like task_setAssignee or task_delegate that also modify assignees.
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 mentions returning a confirmation on success, but lacks critical behavioral context for a creation tool: error handling for duplicate emails, whether the operation is idempotent, authorization requirements, or if the created user is immediately active.
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 efficient sentences with no redundancy. The first sentence front-loads the core action and required fields; the second clarifies the success response. 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?
Given the sensitivity of user creation and complete lack of annotations/output schema, the description should provide more safety context (e.g., 'fails if email exists', 'requires admin role'). It documents fields adequately but leaves operational 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?
With zero parameters defined in the schema, the baseline is 4. The description adds significant value by explicitly listing the expected fields (id, firstName, lastName, email, password) that the schema omits, effectively compensating for the empty schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clear resource ('Operaton user account'), and distinguishes from sibling tools like user_updateProfile by explicitly mentioning credentials (password) and profile fields, indicating this is for initial accountsetup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like user_updateProfile or prerequisites (e.g., admin privileges, checking for existing users). It purely states functionality without contextual selection 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 provided, so description carries full burden. Effectively discloses destructive side effects (cascade deletes instances and history) and lifecycle hook bypassing, giving the agent critical context about data loss risks and behavioral implications.
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 tight sentences with zero waste. Front-loaded with core action, followed by specific behavioral flags. No tautology, no redundant phrases, every sentence 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?
Explains cascade behavior well, but lacks output description (no output schema present) and doesn't clarify failure modes (e.g., behavior when attempting delete without cascade while instances exist), which is important for a destructive operation.
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?
Input schema is empty (0 properties), baseline 4. Description compensates significantly by documenting three critical boolean parameters (cascade, skipCustomListeners, skipIoMappings) and their semantic meanings, though the ID parameter's location (path vs query) is not specified.
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?
Clearly states the specific action (delete) and resource (deployment by ID). Mentions deployment-specific concepts (running instances, history) that help distinguish from similar sibling operations like processInstance_delete or processDefinition_deleteById.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage guidance through flag descriptions (cascade=true for instances/history, skip flags for hooks), but lacks explicit 'when to use vs alternatives' comparisons to siblings like deployment_redeploy.
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 burden. It discloses the 'active' status filter (behavioral trait) but fails to describe return format, pagination, or safety profile. Does not mention that this is read-only vs. the sibling 'incident_resolve'.
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 with zero waste. First sentence states purpose, second states usage context. 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?
Adequate for a zero-parameter tool but missing return value description (critical since no output_schema exists). The description covers what it does and when to use it, but does not complete the picture by explaining what the agent receives back (presumably a numeric count).
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?
Input schema has zero parameters, establishing baseline 4. The description mentions 'matching filter criteria' which adds context that filtering is involved (even if parameters aren't exposed in schema), though this is slightly confusing given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Count' and resource 'active incidents' clearly. Distinguishes from sibling 'incident_list' (which would return details) by emphasizing aggregation. Slight ambiguity with 'matching filter criteria' given empty input schema, though 'active' implies a status filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Use to gauge operational health before investigating individual incidents.' Clearly establishes this as a preliminary diagnostic step before using tools like 'incident_getById' or 'incident_list', though it doesn't name siblings explicitly.
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. Discloses return payload contents (suspension state, override priority) which compensates for the missing output schema. However, omits critical behavioral traits: pagination behavior, read-only nature (not explicitly stated), and whether filters are optional or how they operate.
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 highly efficient sentences with zero redundancy. First sentence states the action and filtering intent; second sentence details specific return values. Information is front-loaded and every clause 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?
Adequately compensates for missing output schema by describing what data is returned (suspension state, override priority) and which entity types are included. Minor gap regarding pagination semantics, but sufficient for a list operation of this scope.
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?
Input schema contains zero parameters, establishing baseline 4 per rubric guidelines. Description mentions 'with filters' which implies parameterization, though this capability is not reflected in the empty schema object.
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-resource combination ('List job definitions') with specific subtype scope ('timer and async service task definitions'). Also specifies return value fields ('suspension state and override priority'), effectively distinguishing from job_list (instances) and jobDefinition_get (single item retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus jobDefinition_get for single-item retrieval or jobDefinition_setSuspension for modifications. No mention of pagination behavior, result limits, or filtering prerequisites despite claiming 'with filters' support.
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 critical behavioral scope ('for all versions') and the unit of measurement ('days'). However, with no annotations provided, it should further clarify the mutation's safety profile—such as whether the change is immediate, reversible, or affects existing historic data versus only new data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two efficient sentences. It is front-loaded with the primary action and scope, though the second sentence ('Controls historic data retention') is slightly generic.
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 empty input schema (which ideally should contain the key and TTL parameters), the description should clarify how inputs are provided. It adequately covers the operation's intent but leaves ambiguity around the mechanism given the schema/implementation 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?
With zero parameters, the baseline score is 4. The description adds semantic value by specifying the unit as 'days', which explains the expected temporal input format even though the schema itself is empty.
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 ('Update'), resource ('history time-to-live'), unit ('in days'), and scope ('for all versions of a process definition by key'). The explicit 'by key' phrasing effectively distinguishes this from the sibling tool processDefinition_setHistoryTtlById.
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?
While 'by key' implies the identifier type, the description lacks explicit guidance on when to use this tool versus the 'ById' variant or other history management tools. No prerequisites or exclusion criteria are mentioned.
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. Adds valuable behavioral constraints: 'active' status filter (suggesting it won't return completed instances) and specific return fields documented since no output schema exists. Missing: error behavior (404 vs null), auth requirements, and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first declares operation and subject, second lists return payload. Every word earns its place; front-loaded with essential action and scope.
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?
Good given constraints: documents return fields to compensate for missing output schema and distinguishes 'active' scope. Deducted one point because error conditions (instance not found, not active) and the ID parameter location (path vs body) remain unspecified, which is critical for a lookup 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?
Input schema has 0 parameters (baseline 4 per rubric). Description adds critical context by mentioning 'by ID', indicating the intended lookup mechanism even though the parameter is not declared in the schema (likely a path parameter or schema omission).
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?
Specific verb 'Retrieve' with resource 'process instance' and scope 'single active'. Implicitly distinguishes from sibling 'processInstance_list' (many vs one) and 'history_listProcessInstances' (active vs historical) via the 'active' qualifier, and from 'processInstance_getVariables' by listing specific identity fields returned (id, definitionKey, etc.).
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?
Implies usage when you have a specific ID, but provides no explicit guidance on when to use alternatives like 'processInstance_list' for searching, 'history_listProcessInstances' for completed instances, or error handling when the ID is not found.
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 disclosure burden. It explains that the error 'trigger[s] the boundary error event on the process,' which describes the mechanism. However, it omits critical behavioral details like whether the task is ended/interrupted, if the operation is reversible, or what permissions are required.
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, optimally structured: first defines the action and mechanism, second states the usage intent. No redundant words or tangential information. Every sentence 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 state-changing operation (mutation) with no output schema and no annotations, the description is adequate but has gaps. It explains the BPMN concept well but doesn't clarify the resulting task state (is it completed? interrupted?) or process side effects beyond the boundary event trigger.
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 contains zero parameters. With no parameters to document, the baseline score applies. The description implicitly confirms parameter-less usage by referencing 'a user task' without qualification, suggesting task context is implicit (likely from the current execution context).
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 specific action ('Throw a BPMN error'), the source ('from a user task'), and the mechanism ('triggering the boundary error event'). While it doesn't explicitly contrast with sibling task operations like task_complete, the BPMN-specific terminology strongly signals its distinct 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 second sentence provides explicit usage context: 'Use to signal an exceptional condition during task execution.' This gives a clear when-to-use scenario. However, it lacks when-not-to-use guidance or named alternatives (e.g., when to use task_complete vs this error throw).
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 disclosure burden. It mentions returning 'matched rule outputs' but omits error handling (no match found?), side effects (audit logging?), or whether this is read-only execution versus state-modifying. Adequate but gaps remain.
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 tightly constructed sentences each serving distinct purposes: capability description, return value explanation, and usage context. No redundancy or unnecessary verbosity.
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?
While concise, the description leaves gaps given the complexity of DMN evaluation: no output schema exists, the input schema is empty (contradicting the implied parameters), and error scenarios are unaddressed. Sufficient for basic identification but not comprehensive guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters in schema establishes baseline of 4. The description adds crucial semantic context that the schema lacks: it mentions requiring a 'key' and 'typed input variables', hinting at dynamic parameter expectations not captured in the empty properties object.
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 provides a specific verb ('Evaluate'), resource ('deployed DMN decision table'), and mechanism ('by key with typed input variables'), clearly distinguishing this execution tool from sibling retrieval tools like decision_getByKey and decision_deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage context ('Used to test decision logic through AI') but lacks explicit guidance on when to use this versus retrieving decision definitions or when evaluation might fail. No prerequisites or alternative workflows mentioned.
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 partially compensates by disclosing return values (decision key, id, version, deployment info) since no output schema exists. However, it fails to mention read-only safety, pagination behavior, or rate limits expected for a list 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?
Three sentences efficiently structured: action (List), filtering capability (Filter by), and return payload (Returns). Every sentence earns its place with no redundancy or filler. Information is front-loaded with the primary action.
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 list tool but missing pagination details (critical for list operations) and explicit read-only confirmation. The parameter/schema mismatch creates ambiguity. Describing return values helps compensate for missing output schema, but behavioral completeness gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema showing zero parameters (empty properties object), the description documents four specific filtering dimensions (key, name, version, tenant). Assuming these are valid query parameters omitted from the schema, the description successfully adds critical semantic meaning necessary for invocation. Baseline 4 for zero params applies, with credit for compensating for schema omissions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear resource 'deployed DMN decision definitions'. It effectively distinguishes from siblings like decision_getByKey (retrieve specific) and decision_deploy (create) by emphasizing the listing/filtering nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies this is for searching/filtering by mentioning 'Filter by key, name, version, or tenant', it lacks explicit guidance on when to use this versus decision_getByKey or decisionRequirements_list. No prerequisites or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses return values ('deployment ID and deployed definition keys'). However, it omits critical behavioral details expected of a mutation tool, including side effects, persistence guarantees, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences that place the core action first ('Deploy...'), followed by specific input requirements and return value documentation. Every clause earns its place with zero 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 zero annotations and an empty input schema, the description partially compensates by describing expected inputs and returns. However, for a deployment mutation it lacks essential context such as versioning behavior, relationship to sibling retrieval tools (e.g., `deployment_getById`), or failure modes.
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?
Given 0 parameters in the schema (baseline 4), the description adds substantive semantic meaning by describing three expected inputs: XML content, filename with extension constraints (.bpmn or .dmn), and deployment name. Note: there is a mismatch between these described parameters and the empty input 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 specific action ('Deploy'), target resource ('BPMN or DMN artifact'), and destination ('Operaton'). It implicitly distinguishes from siblings like `processDefinition_deploy` or `decision_deploy` by indicating support for both BPMN and DMN artifact types in a single operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by specifying required inputs (XML content, filename with expected extensions, deployment name), but lacks explicit when-to-use guidance regarding alternatives such as `processDefinition_deploy` for process-specific deployments.
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 successfully discloses the downstream behavioral effect (cessation of task assignments), but lacks safety-critical details: error conditions (if user not in group), reversibility, idempotency, or authorization requirements.
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 tightly constructed sentences: first defines the operation, second explains business impact. No redundancy or fluff; every clause 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?
Adequate for a focused membership tool, but given no output schema and no annotations, the description should ideally specify the return value format or success indicators. Additionally, error scenarios (e.g., non-member user, non-existent group) are not addressed.
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?
Input schema contains 0 parameters (empty object), triggering the baseline score of 4 per rubric. The description references 'a user' and 'this group' which aligns with the implied operation, though the absence of parameters in the schema suggests they may be passed via context or path not captured here.
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 states the specific action ('Remove') and resource ('user from an Operaton group'), clearly distinguishing from siblings like group_addMember (inverse), group_delete (deletes group), and group_create. The second sentence adds valuable business context distinguishing it from mere membership management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through the consequence statement ('user will no longer receive task assignments'), but lacks explicit when-to-use guidance, prerequisites (e.g., user must be member), or reference to sibling group_addMember as the reversing operation.
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 specific return fields (activityId, name, type, startTime, endTime, duration, assignee) which substitutes for the missing output schema. However, it omits read-only safety confirmation, pagination behavior, and filtering capabilities.
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 efficient sentences with zero waste. First sentence establishes purpose and scope; second sentence enumerates return fields. Information is front-loaded appropriately.
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 phrase 'for a process instance' creates ambiguity given the empty input schema—it's unclear how the process instance is specified. Without annotations or output schema, the description should either explain the input mechanism or remove the qualifier. Return fields are adequately documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, which per guidelines warrants a baseline score of 4. The description mentions 'for a process instance' which implies filtering intent, but this does not constitute parameter documentation since the schema is empty.
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?
Specific verb 'Query' paired with resource 'historic activity instances'. Distinguishes from sibling tools like history_listProcessInstances and history_listTaskInstances by specifying the activity-level scope and mentioning user-task-specific fields (assignee).
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 versus history_listTaskInstances (which also returns task data) or history_listProcessInstances. The mention of user-task fields hints at coverage but doesn't state selection 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 provided, so description carries full burden. It effectively discloses return payload structure (id, type, retries, dueDate, exceptionMessage, process instance details) which compensates for missing output_schema. Could improve by mentioning 404/not-found 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?
Two sentences with zero waste: first states the action, second lists return fields. Information is front-loaded and appropriately sized for the tool's simplicity.
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?
Reasonably complete for a simple retrieval operation with no annotations or output schema. The description successfully compensates for missing return type documentation by listing fields, though it omits error handling details.
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?
Input schema has 0 parameters, but description states 'by ID' implying an ID parameter exists. This creates a significant mismatch between the documented requirement and the formal schema (which is empty), potentially confusing the agent about how to provide 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?
States specific verb 'Retrieve' with resource 'job' and scope 'single job by ID', clearly distinguishing it from sibling list operations like 'job_list' or 'job_count'.
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 context through 'by ID' (i.e., use when you have a specific job ID), but lacks explicit guidance on when to prefer this over 'job_list' or how to obtain the ID initially.
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 async nature, auto-chunking behavior, return values (batch IDs), and dryRun effects. However, with no annotations provided, it omits critical safety context: whether execution is destructive (modifies process instances), permission requirements, or partial failure handling.
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 efficient sentences front-loaded with core action. Each sentence adds distinct value: execution model, chunking behavior, return values, and dryRun capability. No redundancy or filler.
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 immediate operation details well despite absent annotations/output schema, but misses workflow context (relationship to plan generation and status monitoring tools) and lacks destructive operation warnings expected for complex migration tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters in schema triggers baseline 4 per rubric. Description references dryRun mode and instance lists without mapping them to specific inputs, but this doesn't degrade below baseline given the empty schema constraint.
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 specific verb (Execute), resource (migration plan), and execution mode (asynchronously). Distinguishes from sibling migration_generatePlan (planning) and migration_validatePlan (validation) by focusing on actual execution.
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 through dryRun mode (validation vs execution) and auto-chunking (for large instance lists), but lacks explicit workflow guidance—doesn't mention prerequisites like migration_generatePlan or status checking via migration_awaitBatch.
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. Adds useful context about filter capabilities and persistent scoping to MIGRATE_PROCESS_INSTANCE type. However, omits pagination behavior, performance characteristics (history queries are typically expensive), and whether this is read-only (implied by 'Query' but not stated).
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 efficient sentences with zero waste. Main action front-loaded in sentence 1, capabilities in sentence 2, scope constraint in sentence 3. Appropriate density for a query 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?
Adequate for a zero-parameter query tool: covers filter types and batch scope. However, lacks description of return values (no output schema present) and omits behavioral constraints like result limits or history retention boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters in schema triggers baseline 4 per rubric. Description mentions 'Filters: completion status, date range' which suggests filtering capabilities, though schema is empty. This provides conceptual context even if parameter interface is missing.
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?
Specific verb 'Query' + resource 'historic migration batches' + source 'Operaton history log' clearly defines the action. Distinguishes from sibling 'migration_listBatches' via 'historic' designation and specific 'MIGRATE_PROCESS_INSTANCE' batch type scoping.
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 context by specifying 'historic' source and available filters (completion status, date range), but does not explicitly contrast when to use this versus 'migration_listBatches' or other batch query operations. No prereqs or exclusions 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 provided, the description carries full burden. It discloses the conceptual behavior (aggregation of counts per activity) but fails to declare read-only safety, performance characteristics, caching behavior, or the actual return structure/format given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. Front-loaded with the action and resource, followed by use case. Every sentence 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?
Lists the three statistic types returned, partially compensating for missing output schema. However, lacks description of the data structure (array vs object, key names) and behavioral context expected when annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters exist, establishing baseline 4. The description requires no parameter clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' with clear resource 'activity-level statistics for a process definition'. It explicitly lists what statistics are returned (instance counts per activity, failed job counts, incident counts), distinguishing it from sibling 'processDefinition_statistics' which likely returns aggregate data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage via 'Useful for bottleneck analysis' but lacks explicit guidance on when to use this versus siblings like 'processDefinition_statistics' or history APIs (history_listActivityInstances). No 'when-not' or prerequisite guidance 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 provided, so description carries full burden. Adds valuable domain context explaining that 'called' means 'via call activity' (BPMN concept), which clarifies the static dependency nature. However, misses safety/operational details like error handling when ID not found, pagination behavior, or data freshness.
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 tight sentences with zero waste. First sentence front-loads the core action and domain mechanism (call activity). Second sentence provides use case. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with 0 parameters and no output schema. Covers the 'what' and 'why'. Lacks specifics on return structure, error scenarios (e.g., invalid ID), or pagination, which would be necessary for robust agent usage given no output schema is provided.
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?
Input schema has 0 parameters (baseline 4 per rubric). Description mentions 'by a given process definition ID', which semantically compensates for the empty schema by indicating required input context, though it doesn't specify where/how to provide the ID (path vs body vs context).
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?
Excellent purpose clarity: specific verb 'List', resource 'process definitions', scope limitation 'statically called (via call activity) by a given process definition ID', and mechanism clarification '(via call activity)'. Distinguishes from sibling retrieval tools like processDefinition_getById by specifying the 'called processes' relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through 'Useful for dependency analysis', indicating the analytical use case. However, lacks explicit guidance on when to prefer this over processDefinition_getById or processDefinition_list, and contains no 'when-not' warnings 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?
With no annotations provided, the description carries full burden. It adds context that this 'Controls how long historic instances are retained,' explaining the effect. However, it omits critical behavioral details: whether reducing TTL triggers immediate deletion, if changes apply retroactively, or reversibility concerns.
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 efficient sentences with no waste. First sentence captures action, resource, and identifier. Second explains business purpose. Information is front-loaded and every clause 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 this is a configuration mutation with data retention implications, no output schema, and zero annotations, the description lacks behavioral warnings about data deletion risks. However, it adequately covers the functional purpose within its concise scope.
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?
Input schema has 0 properties (empty object), setting baseline to 4 per rules. The description adds 'in days' (unit semantics) and 'by ID' (identifier type), providing valuable semantic context that compensates for the empty schema regarding what parameters would be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Update' with resource 'history time-to-live' and scope 'process definition version by ID'. The 'by ID' clearly distinguishes from sibling tool processDefinition_setHistoryTtlByKey, specifying the identifier type required.
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 mention of 'by ID' implies usage when an ID is available (vs Key for the sibling), but lacks explicit when-to-use guidance or warnings about choosing between ID and Key variants. No alternatives or exclusions are 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 provided, the description carries the full disclosure burden. It adds valuable behavioral constraints: the instance must be 'active' (implying suspension/completion restrictions) and that the operation overwrites existing values. However, it omits other critical mutation behaviors such as error handling for non-existent instances, type validation consequences, or transactional atomicity.
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 consists of three tightly constructed sentences with no redundancy. It follows an optimal structure: primary action declaration first, required inputs second, and behavioral warning (overwrite) third. Every sentence 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 absence of an output schema, empty input schema, and zero annotations, the description provides minimum viable coverage for a mutation tool. It explains the variable-setting operation but fails to document how to specify the target process instance (a critical parameter for this operation type), leaving a significant documentation 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 input schema is empty (0 parameters), establishing a baseline of 4. The description adds essential semantic meaning by explicitly stating the logical parameters required: 'variable name, value, and type'. This compensates for the empty schema. It would achieve a 5 if it also documented the process instance identifier parameter implied by the target resource.
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 specific action ('Set'), the resource ('single named variable'), and the target ('active process instance'). It effectively distinguishes from the sibling tool 'processInstance_setVariables' (plural) by emphasizing 'single', and from 'processInstance_getVariable' by using the verb 'Set'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides behavioral guidance by stating it 'Overwrites any existing value', which informs the user of the destructive/upsert nature. However, it lacks explicit guidance on when to use this singular setter versus the plural 'setVariables', or prerequisite conditions like requiring the process instance ID.
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 full burden. It successfully discloses the destructive overwrite behavior ('Existing variables are overwritten') and state requirement ('active'), but omits transactional semantics (atomicity), side effects on process execution, or failure modes.
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 with zero waste: first establishes scope, second specifies input format, third warns of overwrite behavior. Information is front-loaded and every sentence 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 empty input schema, lack of annotations, and absent output schema, the description provides minimal viable coverage of the operation. However, it omits return value details, specific parameter names, and error handling that would be necessary given the poor structured data richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema-defined parameters (baseline 4), the description compensates by specifying the expected input structure: 'Provide a map of variable names to typed values.' This adds critical semantic context that the empty schema cannot 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 specific action (add or update), resource (variables), target (active process instance), and distinguishes from sibling tools by emphasizing 'multiple variables' and 'single call' to differentiate from processInstance_setVariable.
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 efficiency benefits ('single call') but does not explicitly state when to use this versus the singular processInstance_setVariable or task_setVariables. It mentions 'active process instance' implying state requirements but lacks explicit prerequisites or error 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?
No annotations are provided, so the description must carry full behavioral disclosure. It successfully mentions the return structure (instance ID, state, definition info) which compensates for the missing output schema. It implies mutation via 'Start,' but lacks crucial BPMN-specific context such as idempotency guarantees, synchronous vs asynchronous execution behavior, or what happens if the definition key is not found.
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 consists of three efficient clauses with zero waste. The primary action ('Start a new process instance') is front-loaded, followed by the lookup mechanism ('by definition key'), optional inputs, and return values. Every clause 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 high complexity of BPMN process instantiation and the complete absence of annotations and output schema, the description provides the minimal necessary context (key-based lookup, return values). However, it omits error handling, transaction boundaries, and validation behavior that would be expected for a production-grade workflow engine.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema, the baseline score is 4. The description attempts to compensate for the empty schema by documenting implied parameters ('business key and typed variables'), adding semantic meaning that the structured schema fails to provide. However, this creates a slight tension with the empty schema declaration.
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?
Specific verb ('Start'), specific resource ('process instance'), and precise mechanism ('by definition key'). The phrase 'latest version' clearly distinguishes this from specific-version deployment tools, and the 'by definition key' pattern implicitly distinguishes it from the sibling 'processInstance_startById' tool.
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 by specifying the 'definition key' lookup mechanism, suggesting when to use this (when you have the key and want the latest version) versus the ID-based sibling. However, it fails to explicitly state 'use processInstance_startById instead if you have the ID' or mention prerequisites like deployment existence.
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 burden of disclosing behavioral traits. It compensates for the missing output schema by enumerating return fields (task name, assignee, due date, priority, process instance), but omits mutation safety details, error cases (e.g., task not found), and authorization requirements.
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 efficiently structured: first states the operation and target, second details the return payload. No redundancy or tautology; every word contributes necessary 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?
While the description compensates somewhat for the empty schema by mentioning the ID and listing return fields, gaps remain regarding error handling, the actual location/format of the ID input (given the empty schema), and behavioral edge cases.
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 having 0 parameters in the schema (baseline 4), the description adds crucial semantic information by referencing 'its ID', indicating what input is conceptually required. It also clarifies the return structure, compensating for both empty input schema and missing output 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 specific action (Retrieve), resource (single user task), and identification method (by its ID), effectively distinguishing it from sibling tools like task_list (which returns multiple) and task_update/task_create (which modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its ID' implies usage when a specific identifier is known, providing implicit contrast to task_list for browsing. However, it lacks explicit guidance on when to prefer this over alternatives or error handling (e.g., 'use when you have a specific task ID from a previous task_list call').
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 full burden. It discloses scope persistence ('available in the process after task completion') and hints at type requirements ('Provide typed variable values'), but omits mutation semantics (overwrite vs merge), error behaviors, and authentication requirements.
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 with zero waste. Front-loaded with the core action, followed by scope implications, and ending with input guidance. Each sentence 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?
Adequate for a variable setter with no output schema, but the disconnect between 'Provide typed variable values' and the empty input schema leaves ambiguity about how variables should actually be transmitted (body format, encoding).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage (empty object), baseline is 4. The description mentions 'Provide typed variable values' which hints at expected input intent, though it cannot explain specific fields given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add or update') and resource ('multiple variables on a user task'), explicitly distinguishing it from sibling tools like 'processInstance_setVariables' by specifying 'user task' and implying plurality compared to 'task_setVariable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides temporal context ('available in the process after task completion') implying when data persists, but lacks explicit guidance on when to use this versus 'task_setVariable' (singular) or 'processInstance_setVariables', and omits prerequisites or error 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?
No annotations are provided, so the description must carry full behavioral disclosure. It successfully describes success/failure return patterns ('Returns confirmation on success', 'Returns a not-found error'). However, it omits critical behavioral details for a destructive operation: whether deletion is permanent, cascading effects on user's tasks/process instances, or permission requirements.
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 with zero waste. Purpose is front-loaded in the first sentence. Return behavior is logically sequenced in subsequent sentences. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description covers basic success/error behaviors but leaves gaps regarding side effects (cascading deletions, what happens to orphaned tasks) and reversibility. Adequate but not comprehensive for the risk profile of the operation.
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?
Input schema contains 0 parameters (empty properties object), establishing baseline 4 per scoring rules. The description mentions 'by ID' which hints at the identification mechanism, though this parameter appears to be path-based rather than in the input body.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), specific resource ('Operaton user account'), and identifies the key ('by ID'). It clearly distinguishes from sibling user tools (user_create, user_updateProfile, user_list, etc.) by stating the destructive deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage guidance by describing the error case ('not-found error if the user does not exist'), implying the tool requires an existing user ID. However, lacks explicit when-to-use guidance, prerequisites, or warnings about when deletion might fail or impact other resources.
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 disclosure burden. While it identifies the target state (locked), it omits critical mutation behaviors: required permissions/admin rights, idempotency (can unlock an unlocked user?), return value structure, and error cases (user not found, not locked). For a state-changing operation, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total. First establishes purpose and resource, second provides usage condition. Zero redundant text. Information density is high with no repetition of tool name or tautology.
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 zero-parameter tool with clear singular purpose, but gaps remain for a state-changing operation: no output schema exists, yet description doesn't explain success indicators, failure modes, or side effects. Given the security-sensitive nature of account unlocking, additional behavioral context would improve 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?
Input schema has 0 parameters, establishing baseline 4 per scoring rules. Description appropriately focuses on business logic rather than parameter semantics since none exist. No parameter documentation gaps to compensate for.
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 provides specific verb ('Unlock') + resource ('Operaton user account') + state condition ('locked'). Clearly distinguishes from sibling user management tools (user_create, user_updatePassword, user_updateProfile) by addressing the specific locked account state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when a user has been locked due to failed login attempts.' Provides clear trigger condition for selection. Lacks explicit 'when not to use' or alternative suggestions, but the positive guidance is specific enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It compensates partially by listing return fields ('key, id, version, and deployment details'), but omits safety traits (read-only), error behaviors (404 scenarios), or whether this operation is idempotent.
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 with zero waste: first states purpose and lookup method, second specifies return payload. Front-loaded with the action verb and appropriately scoped for a zero-parameter tool.
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?
Reasonably complete for a simple retrieval tool: compensates for missing output schema by documenting returned fields, and distinguishes itself from XML-fetching sibling. Minor gap: doesn't specify error response when key is not found.
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?
Input schema has 0 parameters (empty properties object), triggering the baseline score of 4 per evaluation rules. The description references 'by its key' which describes the retrieval mechanism rather than documenting a parameter, since no parameters exist in 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?
Specific verb 'Retrieve' + resource 'decision definition' + scope 'latest deployed version by key' clearly defines the operation. Effectively distinguishes from sibling `decision_getXmlByKey` (returns metadata vs XML) and `decision_list` (specific lookup vs enumeration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit context that this fetches the 'latest deployed version' (not a specific historical version), but lacks explicit guidance on when to use this vs `decision_getXmlByKey` or error handling guidance if the key doesn't exist.
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. Mentions 'Query' implying read-only safety and lists specific return fields (id, definitionKey, etc.) since no output schema exists. However, lacks critical behavioral details like pagination, result limits, or performance warnings typical for history queries.
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 well-structured sentences: first establishes purpose and filters, second documents return fields. No redundant text; every clause delivers specific information about capabilities or outputs.
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?
Compensates effectively for missing output schema by enumerating return fields. Distinguishes historic from runtime scope. Could be improved by mentioning pagination behavior or result limits given the 'list' nature and large potential data volume in history tables.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters in schema establishes baseline 4. Description mentions filter criteria (key, business key, state, date range) which, while not reflected in the empty schema, documents intended query capabilities that would otherwise be 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?
Specific verb 'Query' plus resource 'historic process instances' with clear scope. 'Historic' effectively distinguishes from runtime 'processInstance_list' sibling, and 'process instances' distinguishes from sibling history tools (activity instances, incidents, etc.).
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 through 'historic' designation and filter criteria (state active/completed), but lacks explicit when-to-use guidance versus runtime processInstance_list or when to prefer over other history query 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 full burden. Documents specific return fields (name, assignee, endTime, duration, processInstanceId) which provides value, but omits pagination behavior, result limits, data retention policies, or query cost implications.
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 tightly constructed sentences with zero waste. Front-loaded with action verb. First sentence defines scope and filtering, second documents return payload. 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?
Effectively compensates for missing output schema by enumerating key return fields. Given zero parameter complexity and lack of annotations, provides sufficient context for tool selection and basic invocation.
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?
Baseline 4 for 0 parameters per calibration rules. Description references filtering dimensions (process instance, assignee, etc.) which implies query parameters, though schema defines none, creating implementation ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Query' with clear resource 'historic task instances'. Explicitly lists filterable dimensions (process instance, definition key, assignee, completion state) and distinguishes from siblings like history_listActivityInstances or history_listProcessInstances by focusing on task-level data.
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 archival usage via 'historic' and lists queryable fields, but lacks explicit guidance contrasting with runtime task_list for active tasks or when to use this versus other history_* siblings.
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, description carries burden of disclosing behavioral traits. It clarifies the batch type (MIGRATE_PROCESS_INSTANCE) and active state, but omits read-only status, pagination behavior, and return structure.
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 with no waste. Primary purpose stated first, secondary filtering capability second. Appropriate length for a zero-parameter list operation.
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?
Adequate for a simple list operation with no input parameters. Specifies the entity type and active state. No output schema exists, but description appropriately focuses on query intent rather than return structure.
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?
Input schema contains 0 parameters, establishing baseline 4 per scoring rules. Description mentions 'filter by suspended state' which implies parameter existence not reflected in schema, but adds domain context about filtering capability.
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?
Specific verb (List) + resource (migration batches) + scope (active, type MIGRATE_PROCESS_INSTANCE). Clearly distinguishes from sibling migration_listHistoricBatches by specifying 'active'.
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 filtering capability ('Optionally filter by suspended state') but does not explicitly state when to use this tool versus migration_listHistoricBatches or other batch operations.
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 disclosure burden. It identifies the return format (BPMN 2.0 XML), but omits error handling (e.g., 404 for invalid ID), side effects, or permissions required. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence defines the action and resource; the second provides use-case context. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 input parameters, no annotations, and no output schema, the description adequately covers the essentials by specifying the returned data format (BPMN 2.0 XML). It could improve by noting where the ID originates (likely URL path) given the empty 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?
The input schema contains 0 parameters with 100% coverage. Per guidelines, 0 params warrants a baseline score of 4. The description indirectly implies the ID parameter through the tool name and 'by ID' phrase.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), identifies the exact resource ('BPMN 2.0 XML source'), and scope ('by ID'). It clearly distinguishes from sibling tool 'processDefinition_getXmlByKey' by specifying the ID-based lookup method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('Useful for inspecting or debugging'), but lacks explicit guidance on when to use this versus 'getXmlByKey' or other processDefinition tools, and states no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It adds valuable behavioral context by specifying 'latest deployed version' (indicating version selection behavior) and 'BPMN 2.0 XML source' (format). However, it omits operational details like whether this is read-only (implied by 'Retrieve' but not stated), idempotency, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. Front-loaded with the action verb. Every phrase earns its place: 'BPMN 2.0 XML source' specifies format, 'latest deployed version' specifies version scope, and 'by key' specifies the identification method.
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 no output schema exists, the description reasonably covers the return value by specifying 'BPMN 2.0 XML source'. It adequately handles the domain complexity (BPMN/process definitions) by mentioning the specific standard and deployment version. Could be improved by explicitly stating the return type (string vs object).
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 contains zero parameters (baseline 4 for empty schema). The description compensates by specifying 'by key', which implicitly signals that a process definition key is required for operation, adding semantic meaning that the empty schema fails to convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and clearly identifies the resource ('BPMN 2.0 XML source'). It distinguishes scope ('latest deployed version') and methodology ('by key'), clearly differentiating it from siblings like processDefinition_getXmlById (by ID) and processDefinition_getByKey (likely returns metadata, not XML source).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through the 'by key' and 'XML source' qualifiers, distinguishing it from siblings. However, it lacks explicit guidance on when to prefer this over processDefinition_getXmlById or processDefinition_getByKey, and does not mention prerequisites like needing the process definition key.
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. Adds valuable context about hierarchical return structure (tree with sub-processes and execution structure) but omits safety profile (read-only?), error behavior, or authorization requirements expected for a 'get' tool without annotation coverage.
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, zero waste. Front-loaded with core action, second sentence elaborates return structure 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?
Adequately compensates for missing output schema by describing the tree structure and contents returned. No input parameters to document. Could mention read-only nature given lack of annotations, but sufficient for a retrieval tool of this complexity.
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?
Input schema has zero parameters. Per rubric, 0 params = baseline 4. No parameters require semantic clarification.
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 specific verb (Retrieve), resource (activity instance tree), and scope (for a process instance). Second sentence distinguishes content (active activities, sub-processes, execution structure) from flat history lists or basic instance retrieval.
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?
Mentions 'current active activities' implying runtime monitoring use case, distinguishing from historical siblings like history_listActivityInstances. However, lacks explicit when-to-use guidance or named 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 discloses return format ('name, type, and value') and scope limitation ('active' instances only), but omits error behavior (e.g., 404 if instance not found), pagination for large variable sets, or auth requirements.
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 efficient sentences with no waste: action sentence first, return format second, usage intent third. 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?
Reasonably complete given constraints: describes return values (compensating for missing output schema) and distinguishes 'active' scope. Could improve by mentioning path parameter requirements (if any) or warning about potential size of 'all variables' response.
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 has 0 parameters, triggering baseline score of 4. Description appropriately mentions no parameters, remaining consistent with the empty schema 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?
Excellent clarity: 'Retrieve all variables for an active process instance' specifies verb (Retrieve), resource (variables), and scope (active process instance). The word 'all' effectively distinguishes this from sibling processInstance_getVariable (singular) and 'active' distinguishes from history_listVariableInstances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic usage context ('Use to inspect current execution state') but lacks explicit guidance on when to use this vs. processInstance_getVariable (singular) or task_getVariables, and doesn't mention prerequisites like requiring the process instance ID.
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 disclosure burden. Mentions 'immediate execution' but omits critical behavioral details: whether it blocks until completion, returns immediately, requires specific job states, or side effects on job history/logs.
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 well-structured sentences. First defines the action; second provides usage context. No redundant words, properly front-loaded with the core verb.
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 0 parameters and no output schema, the description covers basic intent adequately. However, the mismatch between 'specific job' and empty parameter schema creates ambiguity about job identification, and execution behavior details are absent for a mutation 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?
Input schema has 0 parameters (empty properties object), establishing a baseline of 4. Description correctly avoids inventing parameters, though the phrase 'specific job' raises questions about how the target job is identified given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Trigger' + resource 'job' + scope 'immediate execution'. Distinguishes from siblings like job_get (read), job_setSuspension (config), and job_list (query) by focusing on the execution action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use to manually run a scheduled or async job without waiting for its due date.' Provides clear scenario (manual triggering vs. scheduled trigger), though lacks explicit mention of alternative approaches like job_setSuspension.
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 disclosure burden. Compensates well by enumerating specific return fields (processInstanceId, jobId, failureType, errorMessage, stacktrace) including enum value example (EXHAUSTED_RETRIES). Implies read-only via 'Retrieve' but doesn't explicitly state safety.
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 efficient sentences with zero redundancy: first states purpose, second details return payload structure. No filler words or repetition of tool name. Well front-loaded with the verb 'Retrieve'.
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?
Lists return fields compensating for missing output schema, but fails to explain the paradox between 'one or more migration batches' in description and zero input parameters in schema—critical missing context for how batch filtering/selection is achieved. Should clarify if this returns all batch failures or uses implicit 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?
Input schema contains zero parameters (empty properties object). With no parameters to document, baseline score applies. Description mentions 'one or more migration batches' but doesn't explain how batch selection occurs without input parameters, slightly detracting from perfect 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?
Specific verb 'Retrieve' plus exact resource 'per-instance failure details for one or more migration batches' clearly defines scope. Distinguishes from siblings like migration_getBatchStatus (aggregate status) and migration_getBatchSummary (summaries) by emphasizing granular failure details.
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 debugging/introspection use case via 'failure details' and return fields (stacktrace, errorMessage), but lacks explicit when-to-use guidance versus migration_getBatchSummary or migration_getBatchStatus. No prerequisites or exclusion criteria 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?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context that filters match the list operation, but fails to disclose safety characteristics (read-only vs destructive), authentication requirements, or the specific return value format (integer count).
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 with zero waste: first establishes the action (count), second links to sibling capabilities (filters), third provides usage guidance (pagination planning). Information is front-loaded and 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?
Appropriately complete for a simple count utility. It covers the essential purpose, filter semantics, and usage pattern. Minor gap: without annotations or output schema, it could briefly confirm this returns a numeric count and is read-only, though 'count' implies this sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds semantic value by explaining that the tool accepts 'filter criteria' (referencing the sibling list tool's filter behavior), which compensates for the empty schema by indicating that filtering parameters are expected even if not explicitly defined in the JSON schema properties.
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 counts deployed process definitions and mentions filter criteria support. However, it slightly falters because the input schema shows zero parameters, yet the description references filters, creating a minor ambiguity about how filtering is actually accomplished.
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?
Excellent explicit guidance: it states to 'Use before listing to plan pagination' (when to use) and references the sibling tool 'list' via 'Supports same filters as list' (distinguishing from the retrieval alternative). This directly helps the agent choose between count vs. list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It effectively discloses that suspension prevents new starts and reveals the bidirectional nature (suspend OR activate). It also warns about the cascading effect on running instances. Missing idempotency or permission requirements.
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 tightly constructed sentences with no redundancy. Front-loaded with core action (suspend/activate), followed by behavioral consequence (cannot be started), then optional modifier (includeProcessInstances). Every sentence 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?
Adequate for a state-modification tool given no output schema or annotations: explains the state change and side effects. However, omits return value structure, error conditions (e.g., definition not found), and whether the operation is idempotent.
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?
Input schema shows 0 parameters, yet description references 'includeProcessInstances=true' without clarifying if this is a query param, body param, or how to specify the 'key' or the suspend/activate action state. Creates ambiguity about actual parameter interface despite adding some semantic detail.
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 suspends or activates process definitions by key, distinguishing it from instance-level suspension (sibling processInstance_setSuspension) and ID-based variants (implied by 'by key'). Specific verbs and resource type are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that suspended definitions cannot be started, implying when suspension is appropriate. Mentions includeProcessInstances option to distinguish cascading behavior vs. definition-only suspension. Lacks explicit 'when not to use' or alternative comparison 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?
Without annotations, the description carries the full burden. It adds valuable context about return values ('instance ID, state, and definition info'), but fails to disclose mutation characteristics, side effects, or failure modes for this state-changing 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?
Three sentences, each serving a distinct purpose: action definition, usage guidance, and return value disclosure. No redundancy or 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?
For a complex process instantiation tool with no annotations and empty input schema, the description adequately covers basic purpose and return values. However, it lacks critical operational context regarding side effects, permissions, or error conditions that would be expected for a mutation operation.
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?
Input schema contains 0 parameters, which per evaluation rules establishes a baseline score of 4. The description implies the existence of a process definition ID parameter, but this is not reflected in the provided empty schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action 'Start a new process instance' and the mechanism 'by process definition ID'. It effectively distinguishes from the sibling tool 'processInstance_start' by specifying the particular use case involving definition IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance 'Use when a specific definition version is required', which clearly signals when this tool is appropriate over alternatives. However, it stops short of explicitly naming 'processInstance_start' as the alternative for non-specific versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It successfully clarifies the standalone nature of the created task (distinguishing from process-bound tasks), but lacks disclosure of side effects, idempotency, error conditions (e.g., invalid assignee), or return values.
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, zero waste. The first sentence establishes the core action and scope, the second provides usage context, and the third lists required inputs. Perfectly front-loaded with the most critical information first.
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 absence of annotations, output schema, and the empty input schema, the description leaves gaps regarding return values (e.g., task ID), error handling, and field validation rules. Adequate for basic identification but insufficient for robust agent operation without additional discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), which triggers the baseline 4 rule. The description compensates by explicitly listing four expected parameters (name, assignee, priority, due date) that the schema omits. While it doesn't describe data types or formats, it provides critical param names necessary for invocation.
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 ('Create'), resource ('standalone user task'), and key scope constraint ('not attached to a process instance'). This effectively distinguishes the tool from process-bound task creation (e.g., via processInstance_start) and other task management siblings.
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 contextual guidance by specifying 'ad-hoc work items' and contrasting with process-attached tasks. While it doesn't explicitly name alternative tools, the 'standalone' and 'not attached' phrasing implicitly signals when to use this versus process-instance workflows.
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 key behavioral trait that ownership is retained while completion rights are granted to the delegatee. However, lacks disclosure on reversibility, idempotency, error conditions, or return values given no annotations provide this safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first defines the action, second clarifies the ownership model, third states the use case. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description adequately covers the delegation concept and workflow context. However, given zero parameters and no output schema or annotations, it lacks necessary technical details about how to identify the task/user and what the operation returns.
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?
Input schema contains zero parameters, triggering the baseline score of 4 per evaluation rules. The description implies required inputs (task identifier, target user) through the functional explanation, though these are absent from the provided schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Delegate' with resource 'user task' and distinguishes from siblings like task_claim or task_setAssignee by explicitly stating the original owner retains ownership while the delegated user gains completion rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance ('Use for escalation workflows') indicating when this tool is appropriate, though it does not explicitly contrast with alternatives like task_setAssignee for permanent transfers.
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 successfully discloses the scope hierarchy behavior (returns both task-local and inherited parent process variables), which is critical for variable resolution logic. However, it omits mutability status, error conditions (e.g., task not found), or pagination 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?
Two sentences with zero waste. First sentence establishes purpose; second sentence adds critical behavioral context about scope inheritance. Appropriately front-loaded and sized.
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?
No output schema exists, yet description fails to describe return structure (variable format, types, map structure). Additionally, with empty input schema, it does not clarify how the target task is identified (path parameter vs context), leaving invocation ambiguous despite explaining the retrieval logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present (empty properties object). Baseline score 4 applies as per rubric ('0 params = baseline 4'). Description appropriately makes no parameter claims since there are none to document.
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?
Specific verb 'Retrieve' + resource 'variables' + scope 'user task'. The mention of 'user task' and dual-scope return (task + parent process) effectively distinguishes it from sibling processInstance_getVariables (process-scoped) and task_setVariables (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage by specifying 'user task' context, but lacks explicit guidance on when to use this vs processInstance_getVariables or how to handle cases where variables exist in both scopes (shadowing). No alternatives named.
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 critical side effect ('Overwrites any existing assignee') which is vital given no annotations exist. Missing: return values, error conditions (e.g., task not found), idempotency, or auth requirements that annotations would normally cover.
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 with zero waste. Front-loaded with primary action, second sentence adds critical behavioral warning. 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?
Core functionality and overwrite behavior covered, but with zero annotations and no output schema, description should ideally disclose error conditions or success indicators for this mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per schema, establishing baseline 4. Description references 'specific user' implying expected parameters, but as no schema parameters exist to describe, this baseline holds.
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?
Excellent specificity: states the exact action ('Directly assign a user task'), the target ('specific user'), and distinguishes from sibling tool 'task_claim' by contrasting with the 'claim workflow.'
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 context by contrasting with claim workflow ('without going through'), suggesting when to use this direct assignment over the claim process. Lacks explicit prerequisites or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully adds critical behavioral context about authentication requirements (current password for non-admins) and return values ('Returns confirmation on success'), but omits error conditions, reversibility, or 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 structured: purpose statement, authentication requirement, and return value description. No redundancy or wasted words; each sentence earns its place by conveying distinct information not present in structured fields.
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?
Without annotations or an output schema, the description partially compensates by mentioning return behavior and auth requirements. However, for a sensitive security operation (password update), the absence of error case documentation, permission details for admins, or payload structure leaves 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?
The input schema contains zero parameters (empty properties object), which per evaluation rules establishes a baseline score of 4. The description mentions password requirements but does not explicitly define parameter names or types, though this appears to be a schema limitation rather than a description 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 uses a specific verb ('Update') with a specific resource ('the password for an existing Operaton user'), clearly distinguishing it from sibling tools like user_updateProfile (which handles profile data) and user_create/user_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage constraints ('Requires the current password for non-admin users'), indicating when specific credentials are needed. However, it does not explicitly contrast with user_unlock or state when to prefer this over password reset workflows.
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 disclosure burden. It adds 'Returns confirmation on success' which provides output context absent from schemas. However, it omits critical behavioral details: error handling if user doesn't exist, whether partial updates are allowed (implied by 'or' but not explicit), atomicity, or 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?
Two efficient sentences with no redundancy. Front-loaded with action verb, colon-separated list for scannable parameters, and return value statement. Every sentence 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 empty input schema (0 properties), no annotations, and no output schema, the tool definition is underspecified. While the description lists updatable fields and mentions return value, it lacks error scenarios, field validation rules, or API constraints expected for a user mutation operation with minimal structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters in the schema (empty properties object), the baseline is 4. The description adds specific parameter names (firstName, lastName, email) not present in the schema, providing necessary semantic context. However, it lacks type information, constraints, or required/optional status that a complete schema would 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?
Description clearly states the verb (Update), resource (profile of existing Operaton user), and specific fields affected (firstName, lastName, email). The phrase 'existing Operaton user' distinguishes from user_create, while listing profile fields distinguishes from user_updatePassword (password) and user_getProfile (read-only retrieval).
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 guides usage by specifying 'existing' user (distinguishing from user_create) and specific profile fields (distinguishing from user_updatePassword). However, it lacks explicit when/when-not guidance or direct references to sibling 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?
Adds valuable versioning behavior ('latest version') not captured elsewhere. However, with no annotations provided, description carries full burden and omits safety profile (read-only vs destructive), error handling for missing keys, or auth requirements.
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 efficiently constructed sentences: first defines operation, second states purpose. No redundant words or tautology. Front-loaded with specific technical details (DMN XML).
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?
Appropriate for a simple retrieval tool. Mentions return type ('DMN XML') compensating for missing output schema. Could improve by mentioning whether return is raw XML string or parsed structure, but adequate given scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present; per rubric baseline is 4. Description mentions 'by key' which contextually implies how the resource is targeted, though actual key delivery mechanism (likely URL path) is outside schema scope.
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?
Excellent specificity: 'Retrieve' (verb) + 'DMN XML' (resource) + 'latest version...by key' (scope). Clearly distinguishes from sibling 'decision_getByKey' (likely returns metadata vs XML) and 'processDefinition_getXmlByKey' (different resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'Use to inspect the current decision table logic', explaining the inspection use case. However, lacks explicit contrast with 'decision_getByKey' or alternative approaches like retrieving specific versions vs latest.
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. Specifies operation is for 'failed jobs' only (implicit filter) and implies read-only access via 'Retrieve', but omits details on output format, length limits, or authorization requirements.
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 total. First sentence defines action and target; second states value proposition. No redundant words or tautology. Efficiently 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?
Appropriate for a simple retrieval tool. Mentions return content ('exception stacktrace') despite absence of output_schema, though could specify format (string vs object). Sufficient for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present (schema is empty object). As per rules, 0 params = baseline 4. No parameter documentation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' with specific resource 'exception stacktrace' and scope 'failed job'. Clear distinction from sibling 'job_get' which likely returns general job metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context 'Use to diagnose the root cause of job failures'. Lacks explicit 'when not to use' or alternative suggestions, but clear positive guidance is present.
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 disclosure burden and succeeds in explaining the polling mechanism, timeout behavior, and return structure (COMPLETED vs TIMEOUT with aggregated counts). Minor gap: doesn't clarify if this blocks the thread or how timeout is configured given zero input parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence front-loads the core polling behavior; second sentence precisely documents return values. Every word 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 no output schema exists, the description appropriately documents return values and progress aggregation. Completeness is strong for a zero-parameter tool, though it could clarify batch selection criteria when parameters are absent.
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?
Input schema has zero parameters, establishing baseline 4. The description pluralizes 'batch(es)' which hints at the scope (possibly all active batches), adequately compensating for the empty parameter list without inventing non-existent constraints.
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?
Excellent specificity with clear verb ('Poll'), resource ('migration batch(es)'), and termination conditions ('until all complete or timeout'). The plural 'batch(es)' and await semantics clearly distinguish this from sibling status-check tools like migration_getBatchStatus or migration_getBatchSummary.
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 through 'await' and 'poll' verbs, suggesting this is for blocking/waiting scenarios. However, it lacks explicit guidance on when to use this versus one-time status checks (migration_getBatchStatus) or how to handle the timeout result.
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?
Compensates well for absent annotations by disclosing return contents ('typed errors, sampled-validation flag') and validation scope ('timers, external tasks, cancellations'). However, does not explicitly state whether operation is read-only or has 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?
Single dense sentence efficiently packs purpose, return values, and behavioral scope. Every clause earns its place with no redundant or filler 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?
Despite missing output schema, description adequately details return structure and validation consequences. Covers sufficient complexity for a validation tool, though could explicitly clarify it does not modify state.
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?
Input schema has zero parameters (confirmed by context signals). Description correctly omits parameter discussion. Baseline 4 applies as per zero-parameter rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb ('Validate'), resource ('migration plan'), and scope ('against a set of process instances'). Clearly distinguishes from siblings like migration_generatePlan and migration_executeBatch by focusing on validation rather than creation or execution.
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 context (checking a plan before execution) by mentioning validation and consequence disclosure, but lacks explicit workflow guidance such as 'use this after generatePlan and before executeBatch' or prerequisites.
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 compensates for missing output schema by listing returned metadata fields (key, version, deployment ID, etc.), but omits safety disclosure (read-only nature) and error behavior (e.g., what happens if ID is invalid).
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 efficient sentences: first establishes purpose, second documents return value. No filler or redundancy; every word contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with zero parameters and no output schema, the description is reasonably complete. It compensates for missing schema documentation by enumerating the specific metadata fields returned.
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?
Input schema has 0 parameters, establishing a baseline score of 4. The description implies an ID is required via 'by its unique ID', which aligns with the tool name, though no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), identifies the resource ('process definition'), and clearly scopes the operation to 'single' by 'unique ID'. This clearly distinguishes it from siblings like processDefinition_getByKey and processDefinition_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its unique ID' provides clear context distinguishing this ID-based lookup from processDefinition_getByKey. However, it lacks explicit when-to-use guidance (e.g., 'Use when you have the process definition ID; use getByKey when you have the key').
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, description carries the full burden. It discloses critical behavioral traits: returns 'full metadata' and specifically fetches the 'latest deployed version' (not arbitrary versions). Mentions specific returned fields (version, deployment ID, start form key) compensating for missing output 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 sentences with zero waste. First sentence front-loads the action and scope; second sentence details return value structure. Every word 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 no output schema exists, description adequately compensates by listing returned metadata fields. However, lacks error handling disclosure (what happens if key not found?) and doesn't explicitly confirm read-only safety despite 'Retrieve' verb implying 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?
Input schema contains 0 parameters, establishing baseline 4 per rubric. Description mentions 'by its key' implying a key identifier is required, though schema doesn't show where this is provided (likely path parameter). No additional parameter context needed for empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' with clear resource 'process definition' and scope 'latest deployed version by its key'. The 'by its key' phrase effectively distinguishes this from sibling processDefinition_getById.
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 when-to-use guidance or named alternatives. While the 'by key' qualifier implies distinction from ID-based lookup, it doesn't state when to prefer this over getById or list operations, nor mention prerequisite requirements like deployment existence.
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, description carries full burden. It successfully discloses the async nature and batch job return value, but omits mutation semantics (what 'restart' entails), failure modes, or monitoring requirements using migration_listBatches.
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 with zero waste. Front-loaded with action and return value, followed by specific usage condition. Every word 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?
Adequate for a zero-parameter async operation. Mentions critical batch job return compensating for missing output schema. Could improve by referencing batch monitoring tools, but sufficient for agent selection.
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?
Input schema contains 0 parameters, establishing baseline 4. Description correctly implies no instance-specific filtering is possible via parameters (requires empty property object).
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 specific action ('Restart process instances'), scope ('asynchronously'), and key artifact ('returns a batch job'). The 'Async' suffix combined with 'avoid timeout' clearly distinguishes this from the synchronous sibling tool processDefinition_restartInstances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('when restarting many instances to avoid timeout'), effectively guiding selection over the synchronous alternative. However, it does not explicitly name the sibling tool to avoid.
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 successfully discloses return value details (per-instance eligibility with call-activity blocking conditions) which is crucial behavioral context given no output schema exists. Could improve by mentioning if this is read-only or any rate limiting considerations.
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 three information-dense segments. Purpose stated immediately, followed by return value specifics, then filter capabilities. No redundant words or tautologies. Every element 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 0 parameters and no output schema, description adequately covers the migration-specific return context (blocking conditions) and filter dimensions. Minor gap: could clarify relationship to migration planning workflow or error conditions when no migratable instances exist.
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?
Input schema has 0 parameters (empty object), establishing baseline 4. Description adds value by documenting available filters (definition key, source version, business key pattern) even though they are not formally captured in the JSON schema, suggesting query parameter interface.
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 specific action (List), resource (active process instances), and scope (eligible for migration). Effectively distinguishes from sibling processInstance_list by specifying migration eligibility criteria and call-activity blocking conditions.
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 context through migration-specific terminology (eligible for migration, call-activity blocking), but lacks explicit when-to-use guidance versus alternatives like processInstance_list or migration_generatePlan. No explicit exclusions or prerequisites 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 provided, the description carries the full burden of behavioral disclosure. It adequately explains the state change effects (assignment to user, removal from queues) but lacks critical operational details such as error conditions, prerequisite states (e.g., task must be available to claim), or idempotency characteristics.
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 well-structured sentences with zero waste. The first sentence defines the operation, the second explains the critical workflow consequence (candidate group queue removal) that distinguishes this from other assignment operations. Appropriately 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 zero-parameter simplicity and absence of output schema or annotations, the description covers the essential business logic. It could be improved by mentioning prerequisite conditions or error scenarios, but it is sufficiently complete for a basic claim operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the input schema, the baseline score is 4 per evaluation rules. While the description references 'the specified user' which implies parameters not visible in the provided schema, strictly following the 0-parameter baseline guideline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Claim' with resource 'user task' and clearly distinguishes from siblings by explaining the specific workflow mechanism: 'removed from candidate group queues.' This differentiates it from task_setAssignee (direct assignment) and task_unclaim.
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 about the operational effect (removal from candidate group queues), which implicitly signals when to use this tool—when taking ownership from a candidate group queue. However, it lacks explicit guidance on when NOT to use it or explicit references to alternatives like task_setAssignee.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the ownership transfer effect, but lacks disclosure of side effects, idempotency characteristics, or authorization requirements. The description explains what happens functionally but not operational traits like 'safe to retry' or 'requires admin scope'.
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 with zero waste: first defines the operation mechanics, second provides workflow context. Information is front-loaded with the core action ('Resolve a delegated task') and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a low-complexity state-transition tool with no parameters and no output schema. The description explains the business logic (ownership restoration) that structured fields cannot convey. Minor gap: does not indicate what constitutes success (empty response vs task object) but covers the essential behavioral contract.
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?
Input schema contains zero parameters (empty properties object), meeting the baseline expectation for tools with no arguments. The description does not need to compensate for missing schema documentation since there are no fields to describe.
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 specific action (resolve a delegated task), the resource affected (ownership), and the outcome (returning to original owner). It distinguishes itself from siblings like task_complete or task_delegate by specifically targeting the 'delegated' state reversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit temporal guidance ('Use after the delegate has completed their work') establishing the correct point in the workflow lifecycle. Implies the prerequisite state (task must be delegated) though could more explicitly contrast with task_complete for cases where the task should be finished rather than returned.
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 and effectively explains the side effects: 'clearing the error state and allowing the process to continue or be retried'. Missing auth requirements, reversibility details, or rate limit warnings that would make it 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?
Two sentences totaling 19 words. First sentence captures the action, mechanism, and outcome; second provides the type constraint. No wasted words, well front-loaded with 'Resolve an incident' immediately identifying the operation.
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 mutation tool with no annotations or output schema, the description covers the core operation and side effects but has gaps regarding return values, error conditions (e.g., if incident not found or not resolvable), or what distinguishes custom vs. non-custom incident types.
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?
Input schema has 0 parameters (baseline 4). The description adds semantic value by noting the operation is performed 'by ID', alerting the agent that an identifier conceptually applies even though not reflected in the schema properties. Compensates for empty schema with implicit parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resolves an incident by ID, clearing error states and allowing process continuation. It specifies the resource (incident) and mechanism (clearing error state), and distinguishes from siblings by noting it's 'Only applicable to custom incident types', differentiating it from generic incident operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraint 'Only applicable to custom incident types' indicating when NOT to use it. However, it doesn't mention alternatives like task_resolve or provide guidance on when to prefer this over simply retrying jobs or using other incident 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 provided, the description carries the full burden of disclosure. It effectively communicates the destructive scope (deletes instances, history, and jobs when cascade=true) and the error condition, though it omits reversibility or authorization 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?
Three tightly constructed sentences with zero waste: the first establishes the operation, the second explains the optional cascade behavior, and the third states the failure constraint. Information is front-loaded and dense.
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 destructive operation with no output schema, covering the primary action, parameter behavior, and failure mode. However, it lacks details on return values, success confirmation, or authentication requirements that would be helpful given the high-stakes deletion behavior.
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?
While the input schema shows 0 parameters (baseline 4), the description adds critical semantic information about the cascade parameter (likely a query parameter not captured in the schema), explaining its boolean nature and destructive implications.
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 specific action (Delete), resource (process definition), and identifier scheme (by ID), effectively distinguishing it from the sibling tool processDefinition_deleteByKey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational guidance by explaining the cascade parameter's effect and explicitly stating the failure condition ('Fails if instances exist and cascade is false'), which guides the agent on when the operation will succeed or fail.
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, description carries the full disclosure burden. It clearly states the destructive scope (definitions, instances, history via cascade) and guard conditions (fails when instances exist without cascade). Missing irreversibility warnings or authentication requirements that would be expected for a destructive 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?
Three sentences with zero waste: sentence 1 states purpose, sentence 2 documents the critical cascade parameter and its effect, sentence 3 explains validation logic. Information density is high and front-loaded appropriately.
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 empty input schema and lack of output schema/annotations, the description adequately covers the primary operation (delete by key), side effects (cascade behavior), and error conditions. Could be enhanced with warnings about irreversible data loss or required permissions, but functional completeness is solid.
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?
Input schema is empty (0 parameters), establishing baseline 4. The description compensates by documenting the implied 'cascade' parameter and its boolean semantics (true removes instances/history, false preserves them). It effectively explains the parameter's side effects and validation logic despite schema absence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the destructive action ('Delete'), scope ('all versions'), target resource ('process definition'), and identifier type ('by key'). This clearly distinguishes it from sibling tool 'processDefinition_deleteById' (which deletes a specific version) and 'processInstance_delete' (which deletes runtime instances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit behavioral guidance on the cascade flag ('Set cascade=true to remove all instances and history') and failure conditions ('Fails if active instances exist and cascade is false'). Lacks explicit comparison to 'deleteById' alternative or prerequisite warnings (e.g., required permissions), but the failure condition effectively communicates usage constraints.
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 successfully discloses domain behavior: the task returns to the candidate group queue after unclaiming. However, lacks technical details like permission requirements, idempotency, or error conditions (e.g., what happens if task is already unclaimed).
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 efficient sentences with zero waste. Front-loaded with the action (unclaim), followed by consequence (returns to queue). Every word 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 zero parameters and no output schema, the description adequately covers the essential behavioral context (state transition to candidate group). Could be improved by mentioning authorization requirements or error cases, but sufficient for a simple state-change operation with no inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters per input schema (empty object). With 100% schema coverage trivially satisfied and no parameters requiring semantic explanation, this meets the baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Unclaim' with resource 'user task' and immediate effect 'removing the current assignee'. The second sentence distinguishes this from sibling task_claim by explaining the reverse workflow (returns to candidate group queue vs. taking from queue).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance by describing the outcome state (returns to candidate group queue, available for others to claim), which implicitly defines when to use this (to abandon a claimed task). Lacks explicit 'when not to use' or named alternatives, but the workflow implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explains the mutation nature (implied by 'Set'), the threshold effect for re-enabling execution, and the prerequisite state (failed job). Could explicitly state this modifies job state or requires specific permissions, but covers core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly constructed sentences with zero waste: captures purpose, usage context, and execution requirements. Information is front-loaded with the core action, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty parameter schema and lack of output schema/annotations, the description provides sufficient context for an AI to understand the tool's role in job remediation. Sibling tools provide ecosystem context; this description completes the picture for retry-specific operations.
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?
Input schema has 0 parameters (empty object), establishing baseline 4 per scoring rules. The description adds semantic context for the implied retry value parameter ('1 or more'), explaining valid ranges and intent, compensating for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Set'), resource ('retry count'), and context ('for a failed job'), clearly distinguishing it from sibling tools like job_setSuspension or job_triggerExecution which handle different job lifecycle operations.
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?
Excellent guidance: explicitly states when to use ('after fixing the root cause of a job failure'), provides actionable constraints ('Set to 1 or more to re-enable execution'), and implies this is for remediation rather than routine configuration.
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:

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

Score Badge

Copy to your README.md:

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

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