dolphin-mcp-pilot

Official

by iflytek

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation3/5
Many tools have clearly distinct purposes, but there is overlap between ds_create_workflow and ds_create_dag_workflow (both create workflows, one in simple SQL mode, the other generic DAG) and between ds_update_workflow and ds_modify_workflow_dag (both update workflows). The raw passthrough tools also add a layer of generic capability that could cause confusion.
Naming Consistency4/5
All tools use the ds_ prefix and mostly follow a verb_noun pattern (e.g., ds_list_projects, ds_create_workflow, ds_delete_resource). Minor deviations like ds_online_create_file and ds_complement_data are slightly inconsistent but still readable.
Tool Count2/5
58 tools is a heavy count, especially with niche operations like ds_list_users, ds_list_tenants, and four raw HTTP passthrough methods. While the domain is broad, the sheer number makes selection harder and suggests some tools could be merged or removed.
Completeness4/5
The tool surface is comprehensive for workflow, project, instance, schedule, and resource lifecycle management, including versioning, cloning, and troubleshooting. Missing capabilities include datasource CRUD (only listing is available) and more granular admin operations like user/tenant creation or modification.
Average 3.9/5 across 58 of 58 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 7 community issues answered or closed in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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, the description carries the full burden of disclosing behavior. It only says 'List historical versions,' offering no detail about safety (e.g., read-only nature), pagination behavior, or what the response contains. This is minimal and insufficient for a tool with no structured annotations.
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 short, but the 'Args' section duplicates schema information without clear structure. It is not incorrectly verbose, but it doesn't add enough value to feel fully earned.
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 list tool with no output schema and no annotations, the description should explain return format, ordering, or pagination details. It only names the parameters and the basic action, leaving the agent uncertain about what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats parameter names with minimal elaboration ('Project name', 'Process-definition code', 'Number of items to return'), adding little beyond the schema's titles and types. With 0% schema description coverage, the description should compensate, but it doesn't provide meaningful semantics like parameter constraints or formats.
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 starts with 'List historical versions of a workflow,' which clearly identifies the action (list) and resource (workflow versions). It is distinguishable from siblings like ds_get_workflow or ds_list_workflows, though it doesn't explicitly call out 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?
There is no guidance on when to use this tool versus alternatives such as ds_get_workflow or ds_rollback_workflow_version. The description only states the function, leaving the agent to infer appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Create a new project,' which implies a write operation but omits important details like error handling, naming constraints, or consequences of creating a project with an existing name.
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 extremely brief and front-loaded with the primary action. The args list is clearly structured, though it largely repeats schema information, which slightly reduces its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool and lack of output schema, the description barely covers essential context. It does not mention what the return value is, whether any dependencies exist, or how this tool fits with the abundant sibling tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The listed args 'name' and 'description' add only a modicum of meaning ('Project name', 'Optional description') beyond the schema's titles and default, but they do not clarify formats, constraints, or semantics that would aid correct 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?
The description explicitly states 'Create a new project,' which is a clear verb-resource pairing that distinguishes the tool from sibling tools like 'ds_delete_project' and 'ds_rename_project.' However, it does not elaborate on what a project is in this context, limiting full clarity.
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 or when to prefer an alternative. There is no mention of prerequisites, exclusions, or how this differs from other create-related tools such as 'ds_create_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?
With no annotations, the description alone must disclose behavioral traits. It only says 'pass through' without mentioning side effects, authentication requirements, response format, or potential destructiveness. Since PUT typically modifies resources, this omission is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It front-loads the core information and is appropriately sized for a simple pass-through tool, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter documentation, this one-sentence description is severely inadequate. An agent cannot determine how to construct the request, what the response will be, or what side effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning to the three parameters (path, form_data_json, json_body_json). Parameter names give vague hints, but the description does not clarify expected formats or how they relate to the PUT request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: passing a PUT request to the DolphinScheduler API. It identifies both the HTTP method and the target resource, and the sibling tools (ds_raw_get, ds_raw_delete, ds_raw_post) make the differentiation by method explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about use cases, prerequisites, or situations where another method (GET, DELETE, POST) would be more appropriate. The user must infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It simply states the action 'Resume' but does not mention side effects, permissions, idempotency, error conditions, or whether it only works on paused instances. The word 'paused' adds a minor constraint but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple action and contains only the essential verb and object.
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 with 2 required parameters, no output schema, and no annotations, the description is too sparse. It lacks parameter explanations, usage context, and behavior details. The minimalism is not sufficient to guide an agent effectively, especially with many sibling workflow-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the role of project_name or process_instance_id beyond their names. The phrase 'workflow instance' loosely maps to process_instance_id, but project_name is completely unaddressed. No meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resume' and clear resource 'workflow instance', stating exactly what the tool does. It does not explicitly compare with sibling tools like ds_pause_process_instance or ds_stop_process_instance, but the 'paused' qualifier helps differentiate from those.
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 vs alternatives. The phrase 'paused workflow instance' implies a precondition, but there is no explicit context or exclusions. The description gives no indication of when not to use it or how it differs from rerun operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral effects, but it only says 'activate' without explaining what that entails—whether it changes status, triggers runs, or requires prerequisites. This is insufficient for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence and is front-loaded with the action. However, its brevity omits essential context, making it concise by default rather than through strategic editing.
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 simple mutation tool with two parameters and no output schema, the description says almost nothing beyond the tool's name. It lacks parameter semantics and prerequisite information, so an agent would need external knowledge to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no context for the two parameters (project_name, schedule_id). An agent cannot infer how to find schedule_id or what project_name refers to from this description alone.
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 ('Activate') and resource ('schedule'), clarified by 'bring online.' This clearly distinguishes it from ds_offline_schedule, which is the direct inverse action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The sibling ds_offline_schedule implies the opposite action, but the description does not explicitly state when activation is appropriate, such as after creating a schedule or to resume a paused one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'pass through,' implying a proxy, but does not state that this is a potentially destructive operation, whether any safety checks exist, or what the response format is. This is insufficient for a DELETE operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that states the core functionality with no wasted words. It is structured clearly and ear-loads the main idea.
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 with no annotations, no output schema, and one undocumented parameter, the description is too sparse. It fails to specify the expected path format, the side effects of deleting a resource, or any error handling. This leaves the agent without enough context to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'path' parameter beyond its name. While 'path' is somewhat self-evident as the API path, the description could benefit from a concrete format or example. The parameter adds no additional meaning beyond the schema field itself.
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 passes DELETE requests through to the DolphinScheduler API, using a specific HTTP verb and the target resource. This distinguishes it from sibling tools like ds_raw_get, ds_raw_put, and ds_raw_post, though it does not elaborate on the exact semantic effect of the DELETE operation.
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 raw delete versus the many specialized delete tools (e.g., ds_delete_project, ds_delete_workflow) or the raw_get/put/post siblings. There is no mention of prerequisites, alternatives, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states that the operation is a deletion, implying destruction, but does not mention irreversibility, permissions, impact on logs, or whether the instance must be in a specific state. It adds minimal behavior context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence that is concise and front-loaded with the action. It packs the core purpose into nine words without filler.
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 delete operation with no annotations and no output schema, the description is under-specified. It does not explain what happens after deletion, whether deletion is reversible, or any caveats. While the parameter list is simple, the description's brevity leaves important behavioral details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (project_name, process_instance_id) with no descriptions. The tool description does not mention either parameter, adding no semantic meaning. With 0% schema coverage, the description fails to compensate by explaining what the parameters represent or how to obtain a process instance ID.
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 a historical process instance. The verb 'delete' and resource 'process instance' are specific, and 'historical' distinguishes it from process instance control tools like stop/pause/resume. However, it does not explicitly reference alternatives, so it lacks sibling differentiation.
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?
There is no explicit guidance on when to use this tool versus alternatives such as stopping, pausing, or rerunning a process instance. The usage is only implied by the delete action and the 'historical' qualifier, which suggests it targets completed instances rather than active ones.
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 states the action but does not explain reversibility, effects on running instances, required permissions, or what happens to the schedule after deactivation. This is insufficient for a 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?
The description is a single sentence, front-loaded with the action verb, with no redundant words. It is appropriately sized for the simple operation, and every word earns its place.
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?
The tool has two required parameters, no annotations, and no output schema. The description provides the core purpose but lacks parameter semantics, usage context, and behavioral details. It is not complete enough for an agent to invoke the tool correctly without additional inference.
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 does not mention project_name or schedule_id at all. Input schema has 0% description coverage, and the description fails to explain how these parameters relate to deactivating a schedule. The agent must rely solely on parameter names, which is inadequate.
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 'Deactivate' with a clear resource 'schedule' and the parenthetical 'take offline' clarifies the action. It distinguishes from sibling tools like ds_online_schedule (activate) and ds_delete_schedule (permanent removal), even though it doesn't name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ds_online_schedule or ds_delete_schedule. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage 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.
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 for behavioral disclosure. It only says 'List data sources' without mentioning what the output looks like, whether it is read-only, if there are permission requirements, or if pagination applies. It is minimal and leaves the agent without a clear expectation of side effects or return 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 short and front-loaded with the core action. The Args section adds useful parameter examples without unnecessary verbosity. It earns its place, though it could be even more informative without being verbose. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate but leaves clear gaps. It does not explain what data sources are returned (names? configurations?), how to interpret the 'etc.' in ds_type, or any error/empty-result behavior. The description is sufficient for a basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the ds_type parameter (0% coverage), so the description must compensate. It does so by listing example values ('HIVE / MYSQL / POSTGRESQL / SPARK / CLICKHOUSE etc.'), which clarifies the acceptable domain and implies that this is a filter. This adds meaningful context beyond the schema's bare type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly as 'List data sources' with a specific resource type. However, it does not explicitly differentiate itself from sibling tools like ds_list_resources, which might also list resources of some kind. The inclusion of example ds_type values gives context that this is about data source types, but the distinction is implicit.
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. It does not mention prerequisites, related operations like testing connections, or scenarios where this listing is appropriate. The description simply states the action with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Pause a running workflow instance' without detailing side effects, reversibility, permissions, or behavior when the instance is already paused. This is insufficient for an agent to fully understand the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately front-loaded and easy to parse.
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 there are no annotations, no output schema, and the operation is a state change, the one-sentence description is under-specified. It does not explain prerequisites, effects, return values, or interaction with related tools, making it incomplete for an agent operating in a complex workflow environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention parameters. The parameter names (project_name, process_instance_id) are somewhat self-explanatory, but the description adds no meaning beyond the schema. The agent is left to infer how these parameters relate to the operation.
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 ('Pause') and the target resource ('running workflow instance'), distinguishing it from sibling tools like ds_stop_process_instance and ds_resume_process_instance. The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to pause a workflow instance, but it does not explicitly state when to use it versus alternatives like stop or rerun. No exclusions or alternative recommendations are provided, leaving the context to be inferred from sibling naming.
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 behavioral burden and does add useful disclosures: SQL statements 'executed serially', schedule_start 'defaults to today', schedule_end 'defaults to 2030-12-31', and auto_online meaning 'auto-release workflow and schedule'. However, it does not disclose failure/conflict behavior, what occurs if both mode parameter sets are supplied, or any return-value/success indicators.
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 front-loaded with purpose and organized into mode sections and an Args list, making it scannable. But it is verbose and redundant: the Mode 1 bullet ('Multiple SQL separated by ";;;"') is nearly repeated in the Args line for sql_statements, and the Args list itself restates the mode structure.
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 13-parameter, two-mode creation tool with zero annotations, no output schema, and no nested objects, the description covers most input semantics and defaults adequately. However, with no output schema the description should explain return values/success indicators, and it does not; it also omits error scenarios or duplicate-name behavior, which are notable gaps 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?
Schema description coverage is 0%, so the Args list in the description is the only semantic source, and it compensates well for the key parameters: the ';;;' separator for sql_statements, the JSON array structure for tasks_json/relations_json, 'Quartz 7-field cron expression' for schedule_cron, and explicit defaults. However, several entries are tautological ('project_name: Project name', 'description: Description'), and the mutual exclusivity of the two mode parameter sets is not formally stated.
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 opens with a specific verb+resource: 'Create a workflow (supports simple SQL mode and complex DAG mode)', which clearly states what the tool does. The two modes are well delineated. However, it does not distinguish itself from the sibling ds_create_dag_workflow, which likely overlaps in DAG creation, so it doesn't fully differentiate within the tool family.
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 gives explicit in-tool guidance: 'Provide sql_statements + datasource_id' for Mode 1 and 'Provide tasks_json + relations_json' for Mode 2, and notes Mode 1 is 'backward compatible', implying legacy use. However, it never references alternative sibling tools (e.g., ds_create_dag_workflow, ds_update_workflow) and provides no when-not-to-use or exclusion guidance.
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 responsibility for behavioral disclosure. It does not mention what happens on duplicate folder names, permission requirements, whether intermediate directories are created, or error behavior. Only the action and arguments are stated, offering no insight into side effects or edge cases.
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 brief and well-structured: a one-sentence purpose followed by a compact Args list. Every sentence adds value, with no redundancy or filler, making it easy for an agent to parse quickly.
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 covers the core purpose and parameter semantics but lacks usage context and behavioral details. Given the absence of annotations and output schema, an agent would benefit from additional notes on edge cases or permission requirements, but the description is adequate for a simple create 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 0% schema description coverage, the description effectively compensates by explaining all three parameters. It adds useful context like 'no path prefix' for name, the default '/' for current_dir, and allowed values 'FILE or UDF' for resource_type, which go beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a folder in the resource area' with a specific verb and resource. It distinguishes from sibling tools like ds_online_create_file (file creation) and other ds_create_* tools, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 when to use ds_online_create_file for files instead. There are no exclusions or prerequisites mentioned, leaving the agent to infer usage solely from the action name.
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 must fully disclose behavior. It says it 'passes through' the request, which is a start, but it does not describe authentication requirements, response format, error handling, side effects, or what happens if both body parameters are supplied. The 'choose one' note is ambiguous. This is a significant transparency gap for a tool that makes API calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the core purpose, and uses a clean Args structure. Every line is meaningful: the purpose statement and three parameter definitions. There is no extraneous text or repetition. It is appropriately sized for a low-level pass-through tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic mechanics (HTTP method, path, body types) but lacks important context for real-world invocation: no output schema, no annotations, no mention of response handling, authentication, or error behavior. It also does not clarify how to construct a valid path or the expected format of the body strings. Given the tool's simplicity, this is borderline adequate but missing key details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds useful context: path must start with '/', form_data_json is form-urlencoded as a JSON string, and json_body_json is a JSON string. However, it does not explain how the JSON strings are interpreted, what 'form-urlencoded params as a JSON string' means concretely, or the exact mutual exclusivity beyond 'choose one'. It adds meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pass POST through to DolphinScheduler API', which identifies the verb (POST) and the resource (DolphinScheduler API). It distinguishes from siblings like ds_raw_get, ds_raw_put, and ds_raw_delete by explicitly specifying the HTTP method. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is a low-level pass-through for POST requests but does not explicitly state when to use this raw tool versus higher-level specialized tools (e.g., ds_create_project). It gives a hint about body options ('choose one') but lacks clear guidance on selection criteria or exclusions. There is no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only explains the optional description parameter's behavior ('keeps the existing one if omitted') but does not mention side effects of renaming, permissions required, or what happens on duplicate names or missing projects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the main action, and uses a clear structured format for parameters. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers purpose and parameters. However, it omits return values, error conditions, and any behavioral consequences of renaming. Without annotations or an output schema, this leaves the agent uncertain about the result of the operation, making it minimally complete but not fully contextual.
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% description coverage, but the description provides clear meanings for all three parameters: old_name, new_name, and description (including optional behavior). This effectively compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rename a project' with a specific verb and resource, making the tool's purpose unmistakable. It clearly distinguishes from sibling tools like ds_delete_project, ds_create_project, and ds_rename_resource by focusing on project renaming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or conflict-handling details. The name implies usage, but the description gives no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the action 'roll back' which implies a mutation, but does not explain side effects, reversibility, or whether the operation creates a new version or overwrites the current one. It also does not mention permissions or what happens to the workflow after rollback. This lack of transparency is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear one-sentence purpose followed by a simple argument list. There is no fluff or redundant phrasing. Every line serves a purpose, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 3 required parameters and no output schema. The description covers the essential invocation details, including the source for the version parameter. However, it lacks information about the return value and the behavioral consequences of rollback, which are important for a mutation operation. For a low-complexity tool, it is partially complete but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the description does not add much beyond the parameter titles. It does provide small clarifications: 'workflow_code' is 'Process-definition code' and 'version' is 'Target version number (from ds_list_workflow_versions)'. The version source is useful, but the other parameter descriptions are nearly tautological. Overall, it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Roll back a workflow to a specific historical version.' It identifies a specific verb (roll back), a resource (workflow), and the target (a historical version). This distinguishes it from sibling tools like ds_update_workflow or ds_release_workflow based on the unique rollback action.
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 context by noting that the version comes from ds_list_workflow_versions, suggesting a prerequisite to list versions first. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any conditions or exclusions. The guidance is limited to the version source, which is a helpful but partial cue.
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 for behavioral disclosure. It discloses the 'force kill' behavior, which implies abrupt termination, but does not mention permissions, reversibility, or side effects such as inability to rerun or status changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, and lacks any filler. It earns every word.
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 with no annotations and no output schema, the description is too minimal. It does not provide usage guidance, parameter specifics, or behavioral caveats beyond 'force kill', which is insufficient for an agent to decide when to use it versus pause or resume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters project_name or process_instance_id. The schema titles are self-explanatory but the description adds no semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops a running workflow instance, and the parenthetical 'force kill' distinguishes it from graceful pause or resume operations. This is a specific verb+resource action.
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 forceful termination via 'force kill' but does not explicitly state when to use this tool versus siblings like ds_pause_process_instance or ds_resume_process_instance. It lacks explicit alternative guidance.
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. It states that the tool tests login and connectivity, but does not disclose whether this is a read-only operation, what side effects might occur, whether authentication is required, or what the response/error format looks like. This is minimal for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of six words. It is front-loaded with the verb and resource, contains no redundant information, and 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 that the tool has no parameters and no output schema, the description is minimally complete for understanding its purpose. However, it does not mention the expected result (e.g., success/failure indication) or any error behavior, which would be helpful for a test/connectivity tool. It is adequate but with 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 tool has zero parameters, and the schema is empty (100% coverage vacuously). Per rubric, 0 parameters gives a baseline of 4. The description adds no parameter information because there are none to describe, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Test' and clearly identifies the resource ('DolphinScheduler login and connectivity'). It is not a tautology and is clearly distinct from sibling tools, which focus on projects, workflows, resources, and other operations. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites, exclusions, or typical scenarios (e.g., 'Run this before other DolphinScheduler operations'). The usage is only implied by the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one behavioral trait: the tool takes the schedule offline before deletion. However, it does not mention whether deletion is irreversible, what happens to related resources, or whether any confirmation is required. For a destructive tool, more disclosure is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and a key behavioral detail. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description provides the bare minimum. It lacks information about return values, irreversibility, or any prerequisites. However, the parenthetical about taking offline adds a useful behavioral nuance, making it somewhat complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is 0%, so the description must compensate, but it doesn't. While the parameter names 'schedule_id' and 'project_name' are somewhat self-explanatory, the description adds no additional meaning or context about their roles or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb+resource pair: "Delete a schedule." The parenthetical "takes it offline first" adds useful context about the deletion process and helps distinguish this from related sibling tools like ds_offline_schedule, which only takes a schedule offline without deleting it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for permanent removal of a schedule, and the mention of taking it offline first hints at a two-step process. However, it does not explicitly contrast with alternatives like ds_offline_schedule or state when to use delete vs. offline. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'from the beginning' but does not disclose whether this is destructive, resets state, requires the instance to be in a specific status, or what side effects may occur. For a rerun operation that likely re-executes all tasks, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core action and scope in just six words, which is perfectly concise for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so the description is nearly sufficient. However, for a rerun operation, an agent might need to know prerequisites (e.g., allowed instance states) or effects on running tasks. The description provides the key differentiator ('from the beginning') but omits operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the two parameters (project_name, process_instance_id) or explain how they relate to the rerun. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rerun') with a clear resource ('entire workflow instance') and scope ('from the beginning'). This distinguishes it from the sibling tool ds_rerun_from_failure, which reruns from a failure point.
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 'from the beginning' clearly implies the alternative of rerunning from a failure point, and the sibling ds_rerun_from_failure is easily identifiable. However, it does not explicitly state 'use ds_rerun_from_failure when you need to resume from a failure,' so it falls short of full explicit 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?
With no annotations, the description carries the transparency burden. It discloses implementation details (recursive search via /resources/list, bug avoidance) which adds context, but does not state side effects, permissions, or error behavior. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence purpose, followed by a brief implementation note and structured Args. No filler or redundant information; every sentence adds 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?
For a 2-parameter tool with no output schema or annotations, the description covers purpose, parameters, and implementation, but lacks explicit return structure details beyond 'id and metadata' and does not mention error cases. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides meaningful examples for 'full_name' ('public/test.py' or 'scripts') and clarifies 'resource_type' has a default of FILE, but it does not enumerate allowed values or further specify the resource_type semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Find') and resource ('resource by full path'), with the outcome ('returning id and metadata'). This distinguishes it from sibling tools like ds_list_resources (which lists all) and ds_view_resource (which likely views content).
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 purpose and parameter examples imply when to use this tool (when you have a full path and need id/metadata), but it does not explicitly mention alternatives or when not to use it. The implementation note about avoiding a bug is technical, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing key behavior: the task is marked successful without running and downstream tasks proceed as if it succeeded. It adds a caution about non-critical use. However, it does not discuss reversibility, permissions, or effects on related process state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The core action is front-loaded, followed by a clear warning and consequence. Every sentence adds value with no 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?
For a simple tool, the description covers the core action and important downstream risk. However, with no annotations and zero parameter documentation, an agent would still lack guidance on how to obtain the required IDs and when to prefer this tool over closely related ones like ds_force_task_success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, only providing names and types. The tool description does not explain project_name or task_instance_id, where they come from, or how they relate. The names are somewhat self-explanatory, but the description adds no parameter-level meaning.
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 'Skip' and the resource 'task', explaining 'mark as success without running'. This gives a specific action and outcome. It is distinguishable from siblings like ds_force_task_success because it emphasizes skipping execution, though it does not explicitly contrast itself with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The warning 'Use only for non-critical tasks (e.g., notifications)' provides explicit when-to-use guidance. It also implies a when-not-to-use for critical tasks, but it does not name alternative tools such as ds_force_task_success or ds_stop_process_instance, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it lists users, but does not mention whether the operation is read-only, potential side effects, permissions required, or the structure of the response. The debugging hint is contextual but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and an additional use case. Every word earns its place, and there is no 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?
The tool has no output schema, so the description must compensate by explaining the return value or behavior. It does neither, leaving the agent to infer the response format. However, the tool is simple and has no parameters, so a minimal description is somewhat acceptable, but it still lacks important 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?
The tool has zero parameters, and the input schema is empty. According to the rules, a 0-parameter tool receives a baseline score of 4. The description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list all DS users. It uses a specific verb ('list') and a clear resource ('users'), and it provides an additional debugging context that distinguishes it from sibling tools like ds_list_resources and ds_list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: 'useful for debugging workflow user_id foreign key issues.' This gives a clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it. This is sufficient for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a liveness check (non-mutating) and specifies the focus on scheduler aliveness, but does not describe the response format, error behavior, or any side effects. This is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with a clarifying parenthetical. It is front-loaded, immediately states the verb and target, and contains no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description is minimal but not fully complete. It does not describe the return value or how to interpret the status, nor does it reference related sibling tools like ds_monitor_workers to orient the agent. The lack of an output schema increases the need for such details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input contract. The description adds no parameter information, and none is needed. Given the zero-parameter baseline of 4, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action 'check' and the specific resource 'DS master node status', with the parenthetical 'verify scheduler is alive' further clarifying the exact purpose. It also distinguishes from sibling tools like ds_monitor_workers by explicitly targeting the master node rather than workers.
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 a monitoring use case but does not explicitly state when to use this tool over alternatives like ds_monitor_workers or ds_test_connection. No exclusions or contextual guidance is provided beyond the basic purpose, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it reruns only failed/pending tasks and skips succeeded ones. With no annotations, this is valuable, but it doesn't mention side effects, permissions, or whether the original process instance is mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose and behavior with no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two primitive parameters and no output schema, the description is adequate for selection, but it lacks information about return values, error conditions, or side effects beyond the selective rerun behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the parameters at all. The parameter names are somewhat self-explanatory, but the description fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('resume') and clarifies the scope: rerun only failed and pending tasks, skip succeeded ones. This distinguishes it from sibling tools like ds_rerun_process_instance, which would rerun the entire process.
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 implies usage for recovering from failed tasks, and the parenthetical clarifies the selective behavior. However, it doesn't explicitly name alternative tools or when-not-to-use scenarios, so it's clear but lacks explicit 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 burden. It discloses a key side effect: the tool brings the workflow online first, and explains the partial-run semantics of start_task_names. However, it does not mention return values, prerequisites (e.g., whether the workflow must be offline), or error behavior, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a clean args list. Every sentence earns its place, and the example for start_task_names is valuable without 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, no output schema, and minimal schema descriptions, the description covers the core action and all parameters. However, it omits key contextual information such as what the tool returns (e.g., a run ID), whether it is synchronous, and any prerequisites like workflow offline state. It is adequate for a simple trigger but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful detail for start_task_names (example, downstream inclusion) but project_name and workflow_code are only briefly restated as 'Project name' and 'Process-definition code', adding little beyond the schema titles. The description partially compensates for the lack of schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manually trigger a workflow run (brings it online first)' — a specific verb and resource. It distinguishes from siblings like ds_create_workflow or ds_list_workflows by focusing on triggering an existing workflow run and noting the online-first side effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on how to use the tool, especially the optional start_task_names parameter with an example and explanation that it includes downstream tasks. It implies 'use this to manually run a workflow, leaving empty for full run.' It does not explicitly list alternatives or exclusions, but gives sufficient guidance for the intended use case.
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 shape and the fact that it is a listing (read-like) operation, but it does not explicitly state whether it is read-only, non-destructive, or any potential limitations (e.g., pagination, filtering). The return format adds some transparency, but additional behavioral details would be needed for a higher score.
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 exactly two sentences, totaling only 10 words. It front-loads the verb and resource, states the return format, and includes no redundant or filler content. 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?
For a zero-parameter, read-only listing tool with no output schema, the description provides the essential information: what it lists and the exact structure of the returned objects. It is slightly incomplete in that it does not clarify the scope of 'all projects' (e.g., all accessible to the user, all in the system) or whether the list is sorted, but the overall simplicity makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the description need not explain any parameter semantics. Per the rubric, a zero-parameter tool receives a baseline of 4. The description correctly focuses on the return value instead of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'projects' and explicitly states the return format '[{id, code, name, description}]'. This clearly distinguishes it from sibling list tools such as ds_list_resources or ds_list_workflows, as 'projects' is a unique resource.
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 its usage — when you need to see all projects — but provides no explicit guidance on when to prefer it over alternatives or when not to use it. Since there is no other project-listing sibling tool, this implied usage is adequate, though it lacks explicit exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavior disclosure. It does explain parameter effects (resource_type filtering, full_name as prefix filter from root) but does not describe the return format, pagination, or any side effects. For a simple read-only list, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear one-sentence purpose followed by an Args block. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 optional parameters and no output schema or annotations. The description covers the purpose and parameters sufficiently, but it omits details about the return value structure, which the agent might need to parse results. Given the low complexity, the gap is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows type and default values with 0% coverage. The description compensates by explaining resource_type values (FILE/UDF/ALL) and the meaning of full_name as a path prefix filter, including the empty-from-root behavior. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('resources (files and folders)'), and distinguishes it from sibling tools like ds_view_resource or ds_download_resource. It also clarifies scope by mentioning 'at a given path'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and the meaning of its parameters, implying when to use it (when listing resources at a path). However, it does not explicitly differentiate from alternatives or state when not to use it, so usage guidance is only implicit.
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 behavioral disclosure. The verb 'check' and phrase 'verify task executors are alive' strongly imply a read-only operation, but the description does not explicitly state that it performs no modifications, nor does it mention any failure behaviors or side effects. It adds some context but lacks comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and target resource. Every word contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple monitoring tool with no parameters and no output schema, the description provides sufficient context: it explains what the tool does and the specific verification it performs. It could mention output format or behavior expectations, but given the tool's simplicity, completeness is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter detail needed. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter semantics because there are none to describe, but the schema coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check DS worker node status' with a specific verb and resource. The parenthetical 'verify task executors are alive' adds specificity and distinguishes it from the sibling tool ds_monitor_masters, which presumably checks master nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking worker node health, but it does not explicitly mention when to use this tool versus alternatives like ds_monitor_masters. There's a clear implied context from the name and description, but no explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action and parameter meanings; it does not mention side effects like overwriting existing files, permission requirements, return values, or error behavior. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose followed by a compact, readable Args list. Every line adds value, especially given the schema lacks field descriptions, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameter semantics are well covered, but the tool has no output schema and no annotations, so the description must also explain return values, error behavior, and whether it overwrites existing files. These are absent, leaving the agent without a complete picture of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its fields, but the tool's description adds crucial meaning: file_name is without extension, suffix is without dot and includes examples, current_dir has a default, and resource_type is restricted to FILE or UDF. This richly compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a text file inline (no upload required).' The verb 'Create' and resource 'text file' are specific, and the 'no upload required' phrase differentiates it from sibling tools like ds_upload_file, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when creating a file without uploading—but it does not explicitly state when not to use it or name alternative tools beyond the implication that upload is not needed. The guidance is implied rather than explicit.
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 a key behavioral constraint (path must not include /dolphinscheduler prefix) and implies read-only via GET, but does not mention authentication, error handling, or response format. Given the tool's passthrough nature, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded with action and includes a critical constraint without fluff. 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?
For a simple passthrough tool with one parameter and no output schema, the description covers the essential aspects: what it does, the HTTP method, and path formatting. It doesn't mention response behavior, but that's largely implicit for a raw GET. It could include a hint about using other tools for specific endpoints, but the sibling list helps.
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 single 'path' parameter has no schema description (0% coverage), but the description explains the path requirement (must start with /, exclude /dolphinscheduler prefix), adding meaning beyond the schema. It gives the agent the necessary formatting guidance, though no examples.
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's function with a specific verb ('Pass GET through') and resource ('DolphinScheduler API'), and differentiates from siblings like ds_raw_put/ds_raw_delete by specifying the HTTP method. It also adds a critical path constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use for raw GET requests to endpoints not covered by dedicated tools. However, no explicit when/when-not or alternatives are mentioned. The description only states the mechanism, not when it should be chosen over ds_raw_put or other specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It clearly warns that the operation is 'dangerous,' bypasses actual execution, and only changes the state flag. This is highly transparent about the tool's side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main purpose and a clear warning. Every sentence adds value, with no fluff or redundancy. The formatting with a warning emoji effectively highlights the danger.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 simple params, no output schema, no annotations), the description provides key context: purpose, danger, usage condition, and non-behavior. It is nearly complete, though it could mention prerequisites or consequences of misuse, but those are largely implied by the warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage—neither parameter has a description. The tool description does not explain 'project_name' or 'task_instance_id' at all, providing no additional meaning beyond the self-explanatory parameter names. This is a significant gap for a 2-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Force mark a task as success' and explicitly distinguishes it from actual execution by noting it 'bypasses actual execution' and 'only changes the state flag.' This makes it distinct from siblings like rerun or skip tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage condition: 'Use only when task is stuck/failed but you've verified data correctness.' It also clarifies what the tool does NOT do ('does NOT rerun the task'), which helps prevent misapplication. However, it does not name specific alternative tools, so it falls slightly short of explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It excellently warns that rename may be implemented as delete+recreate, changes resource_id, and can invalidate workflow references. It does not mention permissions or return behavior, but the most critical destructive side effect is clearly highlighted.
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 compact and front-loaded with the core purpose, followed by a critical warning and an Args list. Every sentence earns its place; the Args list somewhat duplicates the schema but includes valuable constraints, so it is not wasteful.
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 annotations and no output schema, the description provides enough context for safe usage: what the tool does, the key risk, and parameter constraints. It lacks details on return values, error behavior, and permissions, but the essential operational context is covered for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for new_name ('filename or folder name only, no path prefix') and resource_type ('FILE or UDF'), which is helpful. However, resource_id and description are only listed by name without further elaboration, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename a resource file or folder' using a specific verb and resource type. It also distinguishes itself from sibling tools like ds_rename_project by specifying 'resource', and the warning about resource_id changes adds further operational scoping.
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 tool's context is clear: it is for renaming a resource file or folder. The warning to check references with ds_list_workflows before proceeding provides a concrete precondition. However, it does not explicitly say when not to use this tool or name alternative tools for other resource 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool supports binary content and explains the two input methods, which is useful. However, it does not disclose side effects (e.g., whether existing files are overwritten), permissions required, or what the response/return value looks like after a successful upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a 'Methods' section, and an 'Args' list. It is slightly longer than necessary but every sentence adds value and the front-loaded opening sentence gives immediate context. 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?
The description covers parameters thoroughly, but it lacks information about the outcome of the upload (e.g., response format, success/failure behavior, or whether it creates vs overwrites a resource). Since there is no output schema, the description should include at least a brief note on what the tool returns or what happens after execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its 5 parameters, but the description explicitly explains every parameter: local_path, file_name, file_content_base64, current_dir, and resource_type. It also clarifies the relationship between parameters (Method 1 vs Method 2) and provides defaults, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Upload a file to the resource area' with support for binary formats like jar/zip. This distinguishes it from sibling tools such as ds_online_create_file (which likely handles text file creation) and ds_update_resource_content (which updates existing content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the two methods for providing file content (local_path vs file_name + base64), making the usage explicit. However, it does not mention when to use this tool over alternatives like ds_online_create_file or ds_update_resource_content, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the core behavior (cloning, optional auto-release) and the return dictionary. However, it does not mention preconditions, permissions, side effects (e.g., whether the new workflow is a deep copy, whether existing names are overwritten, or if there are any destructive implications). For a copy operation this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line purpose, an Args block, and a Returns block. It is concise, front-loaded, and every sentence adds value. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description provides a Returns section with a sample dictionary, which is essential. It also covers all parameters and the auto_online behavior. It does not discuss when to use versus alternatives, but that is covered under usage guidelines. Overall, it is adequately complete for a clone 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?
Schema description coverage is 0%, but the description compensates with an Args list that explains each parameter. It adds meaning beyond the schema, notably 'empty = copy source description' and 'Auto-release after cloning'. This is helpful, though types are left to 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?
Starts with a specific verb+resource: 'Clone/copy a workflow.' This clearly distinguishes it from create_workflow (making something new) and update_workflow (modifying an existing one).
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 clearly implies use when you need to duplicate an existing workflow. It does not explicitly state alternatives or exclusions, but the action is unambiguous and distinct from sibling tools. The parameter list further clarifies the context (source workflow code, new name).
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 behavioral disclosure. It accurately warns that 'Changes take effect immediately' and that workflows referencing the script will use the new version on next execution, which is a significant behavioral trait. However, it omits details about permissions, error handling, or reversibility, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose followed by a warning and an args list. It is front-loaded with the core function, includes a necessary behavioral warning, and contains no filler. Every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 flat parameters, no output schema, no annotations), the description provides enough context for basic usage. It covers the key side effect (immediate workflow impact) and the text-only constraint. However, it does not mention what response to expect or error conditions, which would make it fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides per-parameter explanations: 'resource_id: Resource ID', 'content: New file content', and 'description: Update note (optional)'. While these are minimal, they clarify each parameter's role beyond the bare schema, especially the optional nature of 'description'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update resource file content (text files only).' The verb 'Update' plus the specific resource and content scope distinguish it from sibling tools like ds_rename_resource, ds_delete_resource, and ds_view_resource. The explicit 'text files only' constraint adds important scope clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case (updating resource file content) but does not explicitly contrast with alternative tools such as ds_upload_file or ds_online_create_file. The warning about immediate effects and workflow execution gives contextual guidance, but there is no explicit 'when not to use' or mention of 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 the burden. It explains structural behaviors (e.g., empty 'from' as start node, auto-layout) but does not disclose side effects like overwriting behavior, validation rules, authentication needs, or failure modes. This is a clear gap.
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 long but well-structured with clear sections and examples. Every element earns its place; it could be slightly more concise, but the complexity justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex creation tool with 8 parameters and no output schema, the description covers all necessary details: task types with required fields, relation syntax, cron format, optional locations, and resource formats. It is complete enough for an agent to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates with detailed explanations of every parameter, including task type structures, relation examples, schedule cron format, and resource_list formatting. It even references ds_list_resources() for 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?
The description explicitly states 'Create a generic DAG workflow supporting any task type' with a specific verb, resource, and scope. It distinguishes this from sibling tools like ds_create_workflow and ds_modify_workflow_dag by emphasizing generic task support and the DAG structure.
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 extensive usage context with task type examples, relation semantics, and layout guidance. However, it does not explicitly state when to prefer this tool over alternatives or list exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the dual behavior: if save_to is empty, content is returned as base64; if save_to is provided, it saves to a path accessible to the MCP server process. This includes a crucial environmental constraint (the path is server-side, not client-side). It doesn't mention error cases or side effects, but for a read-only download this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with Args and Returns sections, front-loading the purpose and then providing necessary behavior details. It avoids unnecessary verbosity, though 'resource_id: Resource ID' is slightly redundant.
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?
This is a simple tool with only two parameters and no annotations, but the description covers the essential behavior, return formats, and binary support. It does not discuss possible errors or file size limits for base64 encoding, but given the straightforward nature, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates well. It explains save_to's purpose, its server-side nature, and the empty-string default behavior leading to base64 output. For resource_id, it only says 'Resource ID', adding little beyond the schema, but this parameter is self-explanatory.
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 'Download a resource file' with explicit support for binary formats like jar and zip, which distinguishes it from sibling operations like ds_view_resource. It also explains the two output modes (save-to-path or base64), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use context: download a resource file, especially binary ones, and optionally save to a server-side path. However, it does not explicitly contrast with alternatives like ds_view_resource or ds_get_resource_by_name, and it does not state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: it fetches from the latest failed instance, combines three operational steps, and includes per-step error handling ('v2.0.10: Added per-step error handling — returns partial diagnostic info even if some steps fail'). While it does not explicitly state read-only status or discuss limits, the fetch intent and detailed return structure provide strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening summary, a version note, an Args block, and a Returns block. Every part serves a purpose, though the return schema makes it somewhat lengthy. The layout is front-loaded with the primary function, which aids quick comprehension.
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 annotations and no output schema, the description is remarkably complete: it states the purpose, the composed steps, error behavior, all parameter meanings, and a detailed return structure. The only minor gap is the lack of explicit guidance on when not to use it, but overall it provides a thorough context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by providing an Args section: 'project_name: Project name', 'workflow_code: Process-definition code', and 'log_limit: Lines of log to fetch per failed task (default 500)'. This adds meaningful semantics beyond the empty schema titles, especially clarifying log_limit's purpose and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches all failed task logs from the latest failed instance ('One-click fetch of all failed task logs from the latest failed instance.'). This specific verb+resource differentiates it from sibling tools like ds_get_task_log and ds_list_task_instances by combining multiple steps and targeting the latest failure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is a shortcut for common troubleshooting ('Combines 3 common troubleshooting steps'), clearly indicating when it is useful. However, it does not explicitly mention when not to use it or suggest alternatives, though the combination of steps implies a quick-retrieval scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly indicates this is a read operation ('Read full parameters'), and provides the return structure including task_params, timeout, etc. It also discloses the scope limitation (returns only one task, not the DAG), which is a useful behavioral trait beyond what schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate Args and Returns sections. It is somewhat long due to the JSON example, but this is justified given the lack of an output schema. The front-loaded purpose sentence ensures the main point is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three parameters and no output schema, the description covers purpose, usage scenario, parameter semantics, and return shape. It does not discuss error cases or permissions, but these are less critical for a straightforward read operation. Overall, the description is sufficiently complete for its 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?
Schema coverage is 0%, so parameter descriptions in the tool text are critical. The Args section adds meaningful context: 'workflow_code' is described as 'Process-definition code' and 'task_name' is noted to require 'exact match'. These clarifications go beyond the schema's bare titles and help correct usage.
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 a specific action: 'Read full parameters of a single task'. It explicitly distinguishes this from a larger operation by noting 'returns only that task, not the whole DAG', which differentiates it from sibling tools like ds_get_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?
The description provides a concrete scenario: 'verify a task change took effect', and the rationale 'avoiding pulling a huge DAG payload' implies when to prefer this over a DAG-fetching tool. It does not explicitly name an alternative tool, but the sibling context makes the implied alternative clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination support, default limit, and the return structure, which are useful behavioral traits. It does not mention potential side effects (though 'fetch' implies read-only), error behavior, or permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, an Args list with clear explanations, and a Returns object. Every line adds value, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: what the tool does, how to get the required ID, pagination parameters, and a return structure (compensating for lack of output schema). It does not explain edge cases or the meaning of the 'hint' field, but for invocation purposes it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully compensate. It does: task_instance_id is explained as the ID from ds_list_task_instances, skip_line_num as skipping first N lines for pagination, and limit as max lines with a default of 1000. This adds meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a task execution log, using the specific verb 'Fetch' and resource 'task execution log'. This distinguishes it from sibling tools like ds_get_task_detail (which fetches task details) and ds_get_latest_failure_log (which fetches failure logs), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by specifying that task_instance_id comes from ds_list_task_instances, and explains pagination via skip_line_num and limit. However, it does not explicitly differentiate from sibling alternatives like ds_get_latest_failure_log, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the two modes (empty vs. specified category), the return structure ({category, name, tools, workflow, hint}), and that it is a read-only guide. This is adequate for a non-mutating tool, though it does not address potential side effects (none likely) or deeper behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a single sentence, but the category list is essential for usefulness and is well-organized under 'Available categories.' The 'Args' and 'Returns' sections add structure. Every line serves a purpose, though a shorter version could omit the detailed category descriptions and still function.
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 its simple one-parameter nature and lack of output schema, the description explains input and output sufficiently. It covers the full set of available categories and the return format for both cases. Marked down slightly because the exact semantics of the 'tools' and 'workflow' fields in the result are not described, but this is minor for a help tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by defining the 'category' parameter, listing valid values, and explaining that an empty string returns all categories. This gives the agent enough to choose and pass a category correctly, though it could explicitly state the parameter is optional.
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 'guide' and identifies the resource as 'DolphinScheduler MCP tools.' It clearly differentiates this tool from siblings by framing it as the central navigation/help index, and it lists all categories, making its scope 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?
It provides clear usage guidance: call without arguments to see categories, or with a category name to get tools/workflows. The category list itself serves as a map to alternatives, implying when to use this tool (for orientation) vs. other tools. However, it does not explicitly state when not to use it or name an alternative, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination and the text-only constraint, which are useful behavioral traits. However, it omits details like error behavior on missing resources, maximum line limits, or the output format (e.g., whether lines are numbered). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-line summary followed by a formatted Args list. Every word contributes, and the structure is scannable. It achieves strong clarity in minimal space.
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 paginated read tool, the description covers the inputs and the key constraint (text files only). It doesn't describe the return value format, which could matter, but the lack of an output schema makes this a minor gap. Overall, it's sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully explains each parameter: resource_id's source, skip_line_num meaning 'Number of lines to skip', and limit as 'Max lines to read'. This adds significant meaning beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'View resource file content' which specifies a clear verb and resource, and adds qualifiers 'paginated, text files only' that distinguish it from sibling tools like download or update. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'text files only' clause gives a clear exclusion, implying this tool is not for binary or non-text resources. The parameter source context for resource_id ('from ds_list_resources or ds_get_resource_by_name') also hints at usage. However, no explicit alternatives are named for other file actions, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the cascading nature of the deletion and explicitly warns that it is irreversible, which are critical behavioral traits for a destructive tool. This goes beyond minimal requirements and alerts the agent to the consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extraneous content. It front-loads the core function (delete entire project) and then adds essential context about cascading and irreversibility, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects of the operation: what it deletes, that it cascades, and that it is irreversible. It does not mention potential prerequisites, permissions, or return values, but given the single parameter and lack of output schema, the description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter, project_name, which is self-explanatory and requires no additional clarification. The description does not explicitly reference the parameter but its meaning is directly implied by the tool's purpose. The schema coverage is 0%, but the simplicity of the parameter reduces the need for compensation.
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 deletes an entire project, specifically naming the cascading effect on workflows, schedules, and instances. This distinguishes it from sibling tools like ds_delete_workflow or ds_delete_schedule, which target individual component types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the context for use: it is for deleting a project with all its dependent resources, and warns that the action is irreversible. However, it does not explicitly state when NOT to use it or mention alternative tools for deleting only specific components (e.g., ds_delete_workflow).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It reveals the side effect that DS takes schedules offline when the workflow goes offline and that auto_online_schedule can reactivate them. It also includes a return structure. Missing are permission requirements and idempotency, but the provided behavioral details are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, making it easy to scan. It is slightly verbose (e.g., 'True=online, False=offline' is redundant with the boolean type) but every section serves a purpose. Minimal trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for a simple release toggle: purpose, side-effect, parameter meanings, and return format. It lacks an explicit statement about what happens to running instances or necessary permissions, but given the tool's simplicity and the inclusion of a return schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 0% description coverage, the description explicitly lists all four parameters with their meanings (e.g., 'online: True=online, False=offline', 'auto_online_schedule: Auto-reactivate associated schedule'). This fully compensates for the schema's lack of semantic info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Bring a workflow online or offline.' This clearly distinguishes it from sibling schedule-related tools (ds_online_schedule, ds_offline_schedule) and read-only workflow tools (ds_get_workflow, ds_list_workflows).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: releasing a workflow to online or offline state. It also explains a specific interaction (auto_online_schedule reactivates schedules), which guides usage. However, it does not explicitly state when NOT to use it or compare with alternatives like ds_online_schedule, though the resource focus makes it implicitly 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 transparency burden. It discloses the key behavior that the schedule is created OFFLINE, requires activation, and defaults start/end times. It also notes the cron requirement change. It does not disclose error behaviors or permission needs, but for a create tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a version note and a clear argument list. It is concise but slightly verbose due to the version history, though that information is valuable. Overall, all sentences contribute meaning.
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 create operation with no annotations and no output schema, the description covers the main purpose, key behavior (offline), defaults, and example format. It does not mention what is returned or any potential conflicts, but overall it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully. It explains every parameter: project_name and workflow_code identify the workflow, cron is a Quartz 7-field expression with an example, and start_time/end_time have explicit formats and default values. This is far more informative than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create a schedule') on a specific resource ('workflow'), and clarifies that the schedule is created offline and must be activated with ds_online_schedule. This clearly distinguishes it from sibling schedule tools like ds_online_schedule, ds_update_schedule_cron, and ds_delete_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting the offline creation and the need to activate with ds_online_schedule, plus a rationale for the required cron. It lacks explicit when-not-to-use guidance, but the offline/online distinction serves as a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the HTTP method (PUT), that code is preserved, that version increments automatically, and that the tool can auto-offline/online the workflow (with defaults). These are meaningful behavioral traits beyond a simple 'update' statement. It omits some details like response shape or error conditions, but given no annotation support, this is strong disclosure.
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 front-loaded with a clear one-sentence purpose, followed by the fallback context. The Args block is long but necessary given the 0% schema coverage. It is structured with monospaced formatting and succinct per-parameter annotations. No redundant fluff, though the many parameters inherently lengthen the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no annotations, and no output schema, so the description must cover a lot. It gives a good overview and parameter semantics but does not mention what the response looks like (e.g., success/failure, updated version) or any potential side effects like whether old versions are retained. Given the complexity, the description is sufficient for basic invocation but leaves gaps for edge cases and return-value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description's Args section is essential. It explains every parameter with useful information: task_definitions and task_relations accept list or JSON string, locations defaults to '[]', name and description have 'empty = keep original' semantics, and auto_offline/auto_online have default values. This significantly compensates for the absent schema descriptions, though some explanations are terse (e.g., 'Project name' adds little beyond the name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update workflow definition' which clearly states the verb and resource. It adds specificity with 'PUT method, preserves code, auto-increments version' and explicitly frames it as a fallback to ds_modify_workflow_dag, distinguishing it from the sibling tool. This is a textbook example of purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'This is a fallback when ds_modify_workflow_dag cannot handle the change.' This tells the agent exactly when to choose this tool over the primary alternative. Additionally, it notes that it supports 'full task definition override with complete replacement', which further clarifies its role relative to other update 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. It discloses that the tool 'takes offline first,' that batch deletions are independent, and that one failure doesn't block others. It also documents return structures for both single and batch modes, providing useful behavioral detail beyond the simple 'delete' label.
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 front-loaded with the core purpose and then uses clear sections (Args, Returns) and examples. It includes a version note and batch behavior details, all of which are useful. Slightly verbose but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, no output schema, and no annotations, the description is quite complete. It covers purpose, argument semantics, batch behavior, and return formats for both single and batch modes, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains project_name, clarifies that workflow_code can be an int for single delete or a list for batch delete, and provides concrete numeric examples. This resolves the ambiguity in the schema's anyOf 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 opens with 'Delete workflow(s) by code' which clearly states the specific verb and resource. It distinguishes this from sibling tools like ds_delete_project, ds_delete_process_instance, and ds_delete_resource by focusing on deleting workflows and by their unique code.
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 clearly conveys when to use the tool (deleting single or multiple workflows by code) and gives concrete examples. It does not explicitly mention when not to use it or name alternative tools, but the context is clear and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly labels the operation as 'Read' (non-destructive) and elaborates on the compact mode's behavioral effect: returning only metadata/task summary and reducing token usage. It doesn't mention error behaviors, rate limits, or full response format, but for a simple read operation, key traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring that front-loads the purpose and then uses an Args list for parameter details. Every sentence adds value, especially the detailed compact explanation which justifies its length. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should hint at return values. It does: 'DAG, global params, node coordinates, etc.' and explains compact output as 'metadata and task summary'. The tool is low-complexity with 3 simple params, and the description covers the essential usage and output scope, leaving little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0% covered, so the description fully compensates. It explains each argument: project_name, workflow_code (with its provenance), and compact (with its default and behavioral impact). This adds substantial meaning beyond the bare schema types and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read a single workflow definition', which is a specific verb ('Read') and resource ('single workflow definition') with clear scope. It also lists the components (DAG, global params, node coordinates) and distinguishes from siblings like ds_list_workflows (plural) and ds_get_task_detail (task-level vs workflow-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says workflow_code comes 'from ds_list_workflows', which implies a prerequisite workflow and points to the list tool for discovery. It also explains when to use compact mode ('when you only need to understand DAG structure'), giving clear context. It lacks explicit exclusions or alternatives, but the guidance is more than sufficient for this read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does so by disclosing the merge history, the default behavior of workflow_code=0, and the effect of simplify=True (returning has_schedule/cron/release_state). It does not mention error cases or pagination edge cases, but for a read-only list operation, these are minor gaps. The behavior is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short intro, a version note, bullet points for behavior, and a clear Args block. It is not overly long, and each line contributes useful information. The v2.0.12 merge note is nice for historical context but not essential for operation, slightly reducing conciseness. Overall, it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description covers all the essential operational details: what the list returns, how filtering works, the simplify option, and pagination. The output schema handles return value specifics, so the description need not repeat them. The description is complete enough for an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must explain each parameter. It does: project_name, workflow_code with '0 = no filter', simplify returning a summary dict, and page_no/page_size for pagination. This adds substantial meaning beyond the raw schema, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'List schedule configurations (optionally filtered by workflow_code).' It identifies the action (list) and resource (schedule configurations), and the optional filter distinguishes it from plain list tools. The merge note clarifies its scope relative to older tools, reinforcing distinctness from siblings like ds_set_schedule or ds_delete_schedule.
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 guidance for the primary parameter: workflow_code=0 lists all schedules in the project, while a specific value filters to that workflow. This tells the agent when to use each mode. It does not explicitly describe alternatives among siblings, but the purpose is clear enough that a listing tool is the only read option here. The simplify flag is also explained with its output, adding contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that include_full returns full taskParams/SQL/script and consumes more tokens, and that state can be an empty filter. It also details the return structure. However, it does not explicitly mention that this is a read-only operation or describe potential error conditions, though the 'list' verb implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, a version note, and clearly labeled Args/Returns sections. It is moderately sized and front-loaded. The version note adds a slight redundancy but overall every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return values, parameter behavior, and usage context. It is complete for a list operation, covering both basic and full detail modes. The troubleshooting hint adds valuable context for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully compensates. The Args section explicitly describes each parameter, including state's allowed values and empty behavior, include_full's token impact, and the required identifiers. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists task instances for a process instance, with optional state filtering and full details. This specific verb+resource combination distinguishes it from sibling tools like ds_list_process_instances (which lists process instances) and ds_get_task_detail (which fetches a single task).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for listing task instances within a process instance, with state filtering and an optional include_full parameter for detailed troubleshooting. It does not explicitly name alternative tools, but the version note and parameter explanations imply when to use the toggle. This is strong but not explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List all tenants' clearly implies a read-only, non-destructive operation with no side effects. The description does not contradict any annotations (none exist) and is transparent for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('List all tenants') and adds a brief, relevant parenthetical. Every word earns its place; there is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description fully covers what it does and why someone would use it. The sibling tools context further clarifies its distinct role without requiring elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides all necessary parameter information. The baseline for 0 params is 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all tenants'), with a concise parenthetical explaining its purpose. It is unambiguous and distinct from sibling tools, none of which list tenants.
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 parenthetical '(useful for debugging workflow tenant_id foreign key issues)' provides a specific use case, implying when this tool should be used. It does not explicitly mention when not to use it or alternatives, but given the tool's simplicity and unique function, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses critical behaviors: irreversible deletion, task failures on next execution, the specific error 20018 for non-empty folders, and the recursive deletion behavior. This is rich, actionable context.
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 slightly longer than necessary but every section serves a purpose—warning, behavior, args, returns. The structure is logical and front-loaded with the most important caution. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description fully covers the operation's behavior, parameter semantics, and return format. It addresses the main edge case (non-empty folders) and consequences, making it quite complete for a delete tool with only two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It explains resource_id as Resource ID and clarifies that recursive deletes children for folders with a default of False, adding meaning beyond the raw schema fields. It could elaborate on return fields but is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a resource (file or folder)' with a specific verb and resource type, distinguishing it from sibling delete tools for projects, workflows, etc. It immediately clarifies the scope 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: warns about irreversibility and impact on workflow tasks, and gives explicit guidance on using recursive=True for non-empty folders. However, it does not explicitly reference alternatives among sibling tools, though the purpose clarity implicitly differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It discloses that RUNNING instances with an empty task list are normal, explains next_action hints, and describes filtering behavior. However, it does not explicitly state whether the operation is read-only or describe output structure, though 'List' strongly implies a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for version notes, troubleshooting, and arguments. It is slightly verbose due to version history notes, but every section contributes to understanding or usage. Front-loaded purpose sentence is clear, and the troubleshooting flow is practically useful.
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 and no annotations, the description provides a good amount of context: how to filter, what to do next after getting instances, and expected behavior for states. It lacks explicit return object details and pagination specifics beyond page_size, but for a list tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all four parameters: project_name is identified, workflow_code has clear default/vs specific behavior, state enumerates valid values, and page_size is defined. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool "List process instances" with filters by workflow_code and state, distinguishing it from sibling tools like ds_list_task_instances. It even notes a merged predecessor, adding historical context without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: to get process instances, and when to use ds_list_task_instances for deeper execution details. It also clarifies workflow_code=0 default behavior, which helps select the right invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job: it discloses the default paginated API, auto-fallback to simple-list on failure, case-insensitive fuzzy matching, and the effect of use_simple on underlying SQL. This gives agents a strong understanding of behavior beyond the basic list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, version note, bullet points for behaviors, and an Args section. Slight redundancy exists between bullet points and Args (e.g., search and name are described twice), but the overall organization is logical and front-loaded with the essential verb+resource.
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 list tool with 6 parameters, no output schema, and no annotations, the description covers behavior and parameters thoroughly. It even hints at return shape ('single-element list or empty list' for exact match) and mentions pagination. Missing details like exact response fields or error behaviors are minor given the tool's relatively straightforward list nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides zero description coverage (only titles and defaults). The description compensates fully by explaining each parameter with its semantics, defaults, and constraints (e.g., 'page_no: Page number, starting at 1', 'search: Fuzzy search keyword (name + description)', 'use_simple: Use simple-list endpoint when True'). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List workflow definitions with pagination, search and exact-match support', which is a specific verb+resource+scope statement. It also mentions it merged ds_list_workflows_simple and ds_get_workflow_by_name, clearly distinguishing its functionality from potential 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each parameter (search for fuzzy match, name for exact match, use_simple for bypassing pagination SQL) and explains default behavior. However, it doesn't explicitly state when to use this tool versus a sibling like ds_get_workflow or ds_list_workflow_versions, so it's not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. It discloses the offline/online flow, the auto_online default, and the v2.0.10 change in query behavior. It also documents the return structure. This goes beyond a simple mutation notice and provides useful operational context, though it omits error/failure scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, flow, version note, args, and returns. Each sentence adds value, and the version note about querying the schedule directly is useful context. It avoids redundancy and remains appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, yet the description covers purpose, workflow, parameter semantics, and expected returns comprehensively. It references sibling tools where helpful and explains the auto-online behavior. The tool is moderately complex, and the description is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains all six parameters in detail, including formats for cron and times, the meaning of 'keep original if empty,' and the auto_online default. This fully compensates for the schema's lack of semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Update only the cron expression of a schedule (keeps all other settings).' This distinguishes it from sibling tools like ds_set_schedule, which likely updates full schedule settings. The verb and resource 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?
The description clearly indicates when to use this tool: when only the cron expression needs modification, with a defined workflow (read current state → offline if needed → update → re-online). It also references ds_list_schedules for obtaining schedule_id. However, it does not explicitly state alternatives or when not to use this tool, reducing the score slightly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full burden and excels: it discloses the read-modify-write implementation, versioning with rollback, automatic offline/online behavior, schedule restoration, resource format requirements, field naming compatibility, and the ignored_fields return behavior. This is thorough and exceeds 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?
The description is long but well-structured with clear sections (risk warning, args, operation types, returns, typical scenario). It is front-loaded with the core purpose, and the code blocks and formatting improve scannability. Every section earns its place given the tool's complexity; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex operations object, the description fully covers return values, operation semantics, field compatibility, resource list format, and includes a full typical scenario. It even references a sibling tool (ds_list_resources) for resource lookup. This is contextually complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with exhaustive explanations of all six parameters, including defaults, nuances (e.g., auto_online_schedule implications), and a deep dive into the operations structure. It details all supported action types, field aliases, valid values, and examples, providing far more meaning than the bare schema could.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Modify existing workflow DAG (add/delete/update tasks + adjust dependencies).' This clearly defines the tool's function and distinguishes it from sibling tools like ds_create_workflow, ds_update_workflow, and ds_create_dag_workflow, which handle creation or workflow-level settings rather than DAG structure modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, such as the typical scenario of appending a DEPENDENT node. It also notes that DS has no native 'add single task' API, implying this tool is the workaround. However, it does not explicitly contrast with alternative sibling tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains default serial mode, the risks of parallel mode, and even details the serial ordering guarantee, including the fallback mechanisms and how the format is reported in the return value. This goes well beyond basic operation to explain internal 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?
Despite being long, the description is well-structured with clear sections (Recommended usage, Important, Args, Serial ordering guarantee, Examples). Every sentence adds value: usage warnings, parameter details, and behavioral guarantees. No filler or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete for a complex tool with 8 parameters, no annotations, and no output schema. It covers usage, parameter semantics, and behavioral nuances. However, it only partially describes the return value (the 'format' field), leaving success/error response details unspecified, which is a minor gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates with an explicit 'Args:' section explaining every parameter, including the semantics of start_task_names and task_depend_type. The examples further illustrate how parameters combine, providing meaning that the schema completely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Backfill (complement) workflow data for date range or single partition,' using a specific verb and resource, and clearly distinguishes this from sibling tools like ds_run_workflow or ds_create_dag_workflow by focusing on backfilling existing workflow data. The various usage modes are enumerated, making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed recommended usage patterns for single partition, date range, and task-specific backfills, plus explicit warnings about when to avoid full workflow backfills ('Mandatory standard: don't backfill entire workflow unless full-chain rerun is explicitly needed'). It also references a sibling tool (ds_get_workflow) as a prerequisite, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the automatic 'read → modify → write → online/offline' flow, including the auto_offline, auto_online, and auto_online_schedule toggles and their defaults. It also warns about unrecognized fields being reported in ignored_fields and shows the return structure, making side effects predictable.
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 long but well-structured, leading with a one-line purpose and then using sections for Args, supported fields, warnings, return value, and examples. The front-loading of the purpose and the clear section headers compensate for length, and the extensive field list is essential because the `updates` object has no schema definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fully covers the invocation context: it explains the return format with a concrete example, documents all parameter defaults, lists valid update fields, and notes version-specific behavior (v2.0.11). It is complete enough for an agent to call the tool correctly without additional lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides titles and types, with 0% description coverage, so the description must explain parameters. It does so with an Args block covering all 7 parameters, and it expands the opaque `updates` object with supported field names, snake_case/camelCase aliases, and categories (Common, SQL, SHELL/PYTHON). This goes far beyond the schema and enables correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lightweight single-task parameter update — no need to pass full DAG definition,' clearly identifying a specific verb (update), resource (single task parameter), and distinguishing it from ds_modify_workflow_dag by calling itself a convenience wrapper. It also states the exact use case, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as a wrapper around ds_modify_workflow_dag's update_task and states 'Use case: Change a single task's SQL/script/name/retry params without constructing a full operations list,' which tells when to use it. It contrasts with the full DAG modification tool and provides multiple examples showing typical invocations. This gives clear guidance on when to choose this tool.
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:

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

Score Badge

Copy to your README.md:

[![dolphin-mcp-pilot MCP server](https://glama.ai/mcp/servers/iflytek/dolphin-mcp-pilot/badges/score.svg)](https://glama.ai/mcp/servers/iflytek/dolphin-mcp-pilot)

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/iflytek/dolphin-mcp-pilot'

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