Bio-OS MCP Server

by GBA-BI

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'check_workflow_import_status' and 'check_workflow_run_status' which could cause confusion in monitoring workflows. Additionally, 'compose_input_json' and 'generate_inputs_json_template_bioos' both handle input JSON generation, though their descriptions suggest different contexts (user-provided values vs. template generation). Overall, the tools are well-differentiated, but a few pairs require careful reading to avoid misselection.
Naming Consistency3/5
The naming follows a mostly consistent verb_noun pattern (e.g., 'build_docker_image', 'create_workspace_bioos'), but there are deviations such as 'fetch_wdl_from_dockstore' (verb_noun_preposition) and mixed use of underscores with terms like 'Bio-OS' in names (e.g., 'export_bioos_workspace'). While readable, the lack of a strict convention across all tools reduces predictability.
Tool Count4/5
With 22 tools, the count is on the higher side but reasonable for a comprehensive bioinformatics platform covering Docker builds, workspace management, workflow handling, and IES instances. It feels slightly heavy but not excessive, as each tool appears to serve a specific function in the domain without obvious redundancy.
Completeness5/5
The tool set provides complete coverage for the bioinformatics domain, including CRUD operations for workspaces and IES instances, workflow lifecycle management (import, validate, submit, monitor, delete), and supporting utilities like Docker image handling and input generation. No significant gaps are apparent; agents can perform end-to-end tasks without dead ends.
Average 2.6/5 across 22 of 22 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on December 12, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('build') without any details on what happens during the build (e.g., whether it pushes to a registry, requires authentication, has rate limits, or is destructive). For a tool that likely involves complex operations, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('构建 Docker 镜像'), which is overly concise to the point of under-specification. While it's front-loaded, it lacks necessary detail, making it inefficient rather than appropriately sized for a tool with complex parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (building Docker images involves multiple steps and parameters), lack of annotations, and 0% schema description coverage, the description is completely inadequate. Although an output schema exists (which might help with return values), the description fails to provide any context on behavior, usage, or parameters, leaving critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters (config with nested properties like repo_name, tag, source_path) are described in the schema. The description adds no information about these parameters, failing to compensate for the schema gap. It doesn't explain what 'config' entails or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '构建 Docker 镜像' is a direct translation of the tool name 'build_docker_image', making it tautological. It doesn't specify what kind of Docker image is being built, for what purpose, or how it differs from sibling tools like 'get_docker_image_url'. While the verb 'build' is clear, the resource 'Docker image' is generic without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a Dockerfile), when not to use it, or how it relates to sibling tools like 'check_build_status' or 'get_docker_image_url'. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but fails to disclose behavioral traits. It doesn't mention whether this is a read-only operation, if it requires authentication (implied by ak/sk parameters but not stated), rate limits, output format (though output schema exists), or side effects like writing files to 'output_dir'. The description is minimal and offers no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, which is concise but under-specified rather than efficiently informative. It's front-loaded with the core action but lacks necessary details, making it more of a placeholder than a helpful summary. While not verbose, it fails to earn its place by adding 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 complexity (1 nested parameter with 6 sub-parameters, no annotations, but an output schema exists), the description is incomplete. It doesn't address authentication needs, output behavior (e.g., file writing to 'output_dir'), or how it differs from siblings. The output schema mitigates some gaps, but the description alone is inadequate for safe and effective use.
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 but adds no parameter information. It doesn't explain what 'config' contains, the role of 'workspace_name' and 'submission_id', or optional fields like 'ak', 'sk', and 'output_dir'. With 1 parameter (a nested object with 6 sub-parameters) and no schema descriptions, this leaves parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作流执行日志' (Get workflow execution logs) states the basic action but is vague about scope and format. It doesn't specify whether this retrieves all logs, filtered logs, or real-time logs, nor does it distinguish from sibling tools like 'check_workflow_run_status' or 'get_ies_events' that might also provide workflow-related information. The purpose is identifiable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With siblings like 'check_workflow_run_status' and 'get_ies_events' that might overlap, there's no indication of prerequisites, timing (e.g., after submission), or exclusions. This leaves the agent guessing about appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('retrieve workflows') without any details on permissions, rate limits, pagination, error handling, or what the output entails. For a search tool with complex parameters and an output schema, this lack of behavioral context is inadequate and leaves the agent guessing about operational traits.
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 concise with a single sentence, but it's under-specified rather than efficiently informative. It's front-loaded with the basic action but lacks necessary details, making it feel incomplete rather than streamlined. While not verbose, it fails to earn its place by omitting key information for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter with 6 nested properties, 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It doesn't compensate for the lack of schema documentation or annotations, and while the output schema might cover return values, the description fails to explain input semantics, usage context, or behavioral traits, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description adds no parameter semantics beyond the tool's name—it doesn't explain the 'config' object, its nested properties like 'query', 'top_n', or 'get_files', or how they affect the search. With 1 parameter and 6 nested properties, this is a critical gap that hinders correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在Dockstore中检索工作流' (Search workflows in Dockstore) states the basic action and resource but is vague about scope and differentiation. It doesn't specify what kind of search (e.g., by metadata, content, or tags) or how it differs from sibling tools like 'fetch_wdl_from_dockstore' or 'import_workflow'. This is a tautological restatement of the tool name without meaningful elaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., when searching is needed), or exclusions. Given sibling tools like 'fetch_wdl_from_dockstore' and 'import_workflow', there's no indication of how this search tool fits into the workflow lifecycle, making it misleadingly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to do so: it does not indicate if this is a read-only or destructive operation, what permissions are required, potential side effects, rate limits, or what the export entails. The description lacks any behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no wasted words. It is front-loaded and efficiently states the tool's action, though it lacks depth. Every word earns its place in conveying the basic intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (export operation with 1 parameter but nested properties), no annotations, and 0% schema coverage, the description is incomplete. It does not explain what metadata is exported, the format, or how it relates to the output schema. While an output schema exists, the description fails to provide necessary context for tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no parameter information—it does not explain what 'cfg' contains, the purpose of fields like 'ak', 'sk', or 'export_path', or how parameters interact. This leaves all parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bio-OS 导出工作空间元信息' restates the tool name 'export_bioos_workspace' in Chinese, making it a tautology. It does not specify what '导出' (export) entails or what '元信息' (metadata) includes, nor does it distinguish this tool from sibling tools like 'list_workspace' or 'create_workspace_bioos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or comparisons with sibling tools such as 'list_workspace' or 'create_workspace_bioos', leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool queries status, implying a read-only operation, but doesn't clarify authentication needs (e.g., the 'ak' and 'sk' parameters suggest required credentials), rate limits, error conditions, or what the status response entails. This leaves significant gaps for safe and effective use.
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 in Chinese ('查询工作流导入状态') that directly states the tool's purpose without unnecessary words. It's appropriately front-loaded with the core action, though it could benefit from additional context to improve usability without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving authentication and specific resource queries), lack of annotations, and 0% schema description coverage, the description is insufficient. While an output schema exists (which mitigates the need to describe return values), the description doesn't compensate for missing behavioral and parameter details, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions, placing full responsibility on the tool description. The description adds no information about parameters, failing to explain the required 'config' object or its nested fields (e.g., 'workspace_name', 'workflow_id', 'ak', 'sk', 'endpoint'). This leaves all parameters undocumented and ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询工作流导入状态' (Query workflow import status) clearly states the action (query/check) and resource (workflow import status), providing a basic understanding of the tool's function. However, it doesn't differentiate from sibling tools like 'check_workflow_run_status' or 'check_build_status' that also perform status checks on different resources, leaving ambiguity about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after using 'import_workflow'), exclusions, or relationships to sibling tools like 'check_workflow_run_status' for run status versus import status. Without such context, an agent must infer usage from the tool name alone.
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. The description only states what the tool does ('query workflow run status') without revealing any behavioral traits. It doesn't mention whether this is a read-only operation, what permissions are required, whether it has rate limits, what format the status information returns in, or any side effects. For a tool with no annotation coverage, this is a significant 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 extremely concise at just one phrase ('查询工作流运行状态'). While this brevity reflects under-specification rather than optimal conciseness, it contains no wasted words and is front-loaded with the core purpose. Every word earns its place, even though more content would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (checking workflow run status with authentication parameters), no annotations, and rich parameter structure, the description is incomplete. While an output schema exists (which reduces the need to explain return values), the description doesn't address critical context like authentication requirements (ak/sk parameters), workspace context, or how this differs from other status-checking tools. For a tool with authentication parameters and sibling alternatives, this description is inadequate.
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 provides zero information about parameters, while the schema has 0% description coverage. The single 'config' parameter contains nested properties (workspace_name, submission_id, ak, sk, endpoint), but the description doesn't explain what these mean or how they relate to checking workflow run status. With low schema coverage, the description fails to compensate by adding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询工作流运行状态' (Query workflow run status) is a tautology that essentially restates the tool name 'check_workflow_run_status'. It specifies the verb ('query') and resource ('workflow run status'), but doesn't distinguish this from sibling tools like 'check_build_status' or 'check_ies_status' beyond the resource name. The purpose is clear but lacks differentiation from similar status-checking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple status-checking sibling tools (check_build_status, check_ies_status, check_workflow_import_status), but the description doesn't explain when this specific workflow run status tool is appropriate versus those others. No context about prerequisites, timing, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('下载工作流' - download workflow) without mentioning any behavioral traits such as whether it requires authentication, has rate limits, what happens if the download fails, or what the output looks like. For a tool with zero annotation coverage, this is a significant 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 extremely concise with a single sentence '从Dockstore下载工作流' (download workflow from Dockstore). It's front-loaded and wastes no words, though this conciseness comes at the cost of completeness. Every word earns its place in conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, schema description coverage is 0%, and the tool has a parameter (config with url and output_path), the description is incomplete. While an output schema exists (which reduces the need to describe return values), the description doesn't address behavioral aspects, parameter meanings, or usage context. For a download operation that likely involves network calls and file system operations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters. With schema description coverage at 0% (the schema has descriptions but they're minimal and generic), the description doesn't compensate by explaining what 'config' contains, what format the 'url' should be, or what 'output_path' means. For a tool with 1 required parameter (a nested object with 2 properties), this leaves significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as '从Dockstore下载工作流' (download workflow from Dockstore), which provides a clear verb ('下载' - download) and resource ('工作流' - workflow). However, it doesn't differentiate from sibling tools like 'search_dockstore' or 'import_workflow', leaving ambiguity about when to use each. The purpose is clear but 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 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. With sibling tools like 'search_dockstore', 'import_workflow', and 'validate_wdl', there's no indication of whether this tool is for initial downloading, validation, or import processes. No explicit or implied usage context is 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation operation ('新建'), implying it's a write/mutation tool, but doesn't mention permissions required, whether it's idempotent, error conditions, or what happens on success (e.g., returns an IES ID). For a creation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that states the action, location, and purpose without unnecessary words. It's appropriately sized for a basic tool description, though it could be more structured (e.g., separating purpose from parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a creation tool with 12 nested parameters) and no annotations, the description is incomplete. It doesn't explain the parameters, behavioral traits (e.g., side effects, errors), or reference the output schema (which exists but isn't mentioned). For a tool of this complexity, the description should provide more guidance to complement the structured data.
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 mentions no parameters at all, while the input schema has 1 parameter ('cfg') that is a complex nested object with 12 sub-properties. With 0% schema description coverage (the schema itself has descriptions for all properties, but the tool description doesn't reference them), the description fails to add any semantic context beyond what's in the schema, leaving the agent to rely solely on the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('新建一个 IES 实例' - create an IES instance) and the resource ('在指定的workspace中' - in a specified workspace), and mentions the purpose ('用户可在该 IES 实例上进行分析' - users can perform analysis on this IES instance). It doesn't explicitly differentiate from sibling tools like 'create_workspace_bioos' or 'check_ies_status', but the purpose is clear 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 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 doesn't mention prerequisites (e.g., needing an existing workspace), exclusions, or compare it to sibling tools like 'create_workspace_bioos' (for creating workspaces) or 'check_ies_status' (for monitoring IES instances). The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a new workspace, implying a write operation, but does not disclose any behavioral traits such as permissions required, whether creation is idempotent, error handling, or rate limits. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 phrase in Chinese ('Bio-OS 创建新工作空间'), which is appropriately concise and front-loaded. It wastes no words, though it could benefit from more detail to improve clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with nested parameters) and the absence of annotations, the description is minimally adequate. It states the purpose but lacks behavioral context, usage guidelines, and parameter insights. The presence of an output schema helps, but the description does not leverage this to provide a complete picture, leaving gaps in understanding the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, but the schema itself includes detailed descriptions for all nested properties (e.g., 'workspace_name', 'ak', 'endpoint'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate for or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bio-OS 创建新工作空间' clearly states the action (创建/创建) and resource (工作空间/workspace) in Chinese, which translates to 'Bio-OS creates a new workspace.' This is a specific verb+resource combination. However, it does not differentiate from sibling tools like 'list_workspace' or 'export_bioos_workspace,' which limits its clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as authentication via 'ak' and 'sk' parameters, or compare it to sibling tools like 'list_workspace' for viewing existing workspaces. This lack of context makes it unclear when 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 carries the full burden of behavioral disclosure. The description only states what the tool does (gets a URL) without explaining behavioral traits such as whether this is a read-only operation, if it requires authentication, what happens if the image doesn't exist (e.g., returns an error), or rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('获取 Docker 镜像的完整 URL'), which is front-loaded and wastes no words. Every part of the sentence contributes to understanding the tool's purpose, making it efficient and well-structured for its brevity.
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 moderate complexity (1 nested parameter with 5 sub-parameters), no annotations, and an output schema (which likely describes the returned URL), the description is minimally complete. It states the core function but lacks details on behavior, parameters, and usage context. The output schema might cover return values, but the description doesn't address prerequisites or error conditions, leaving gaps for an AI agent.
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 adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, meaning parameter descriptions in the schema are minimal or generic (e.g., '仓库名称' - repo name). The tool has 1 parameter (a nested object with 5 sub-parameters), but the description doesn't explain what 'config' should contain, how parameters like 'registry' or 'namespace_name' affect the URL, or provide examples. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取 Docker 镜像的完整 URL' (Get Docker image's complete URL) states a clear purpose with a specific verb ('获取' - get) and resource ('Docker 镜像的完整 URL' - Docker image's complete URL). However, it doesn't distinguish this tool from its sibling 'build_docker_image' - both relate to Docker images but serve different functions (URL retrieval vs. image building). The purpose is clear but 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 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. There's no mention of prerequisites (e.g., whether the image must already exist), context for usage (e.g., after building an image), or comparison with sibling tools like 'build_docker_image' (which might create the image first). Usage is implied only by the tool name and description, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions both submission and monitoring, but doesn't describe what 'monitor' entails (polling behavior, output format, error handling). For a workflow execution tool with potential side effects, the description doesn't address permissions needed, whether submission is idempotent, what happens on failure, or rate limits. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 Chinese characters ('提交并监控 Bio-OS 工作流'). While this may be too brief for adequate tool understanding, it represents perfect conciseness with zero wasted words. The structure is front-loaded with the core action, though it lacks any elaboration.
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 complex workflow submission tool with 14 parameters, no annotations, and sibling tools offering related functionality, the description is severely incomplete. While an output schema exists (which helps), the description doesn't address critical context like: what happens after submission, how monitoring works, error conditions, authentication requirements (though schema covers AK/SK), or how this integrates with the broader Bio-OS ecosystem represented by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information, but the input schema has 100% description coverage (all 14 parameters in SubmitWorkflowConfig have detailed descriptions). Since schema_description_coverage is effectively 100% (though technically 0% at the top level, all nested properties are documented), the baseline score of 3 is appropriate. The description adds no value beyond what's already in the comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '提交并监控 Bio-OS 工作流' (Submit and monitor Bio-OS workflow) states the basic action but is vague about scope and differentiation. It mentions both submission and monitoring, but doesn't specify what distinguishes this from sibling tools like 'check_workflow_run_status' or 'delete_submission'. The purpose is understandable but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'check_workflow_run_status', 'delete_submission', and 'get_workflow_logs', the description offers no indication of when this submission+monitoring tool is appropriate versus using separate tools for submission and monitoring. There's no mention of prerequisites, typical use cases, 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 carries full burden for behavioral disclosure. While it mentions uploading files/directories, it doesn't describe what happens during import (e.g., validation, overwrite behavior, permissions needed, rate limits, or error handling). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that states the core purpose and scope (supports single files or directories). It's front-loaded with the main action and has no wasted words, making it easy 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?
Given the tool's complexity (upload/import operation with a nested config object) and the presence of an output schema (which relieves the description from explaining return values), the description is minimally adequate. However, with no annotations and poor parameter coverage, it lacks critical context about behavioral traits and parameter meanings, making it incomplete for safe and effective use.
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 provides zero information about parameters. With schema description coverage at 0% (the schema has no descriptions at the top level, only within nested definitions), the description fails to compensate. It doesn't mention the required 'config' parameter or any of its nested fields like workspace_name, workflow_source, etc., leaving the agent with no semantic understanding beyond the bare 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 clearly states the tool's purpose: '将 WDL 工作流上传到 Bio‑OS' (upload WDL workflows to Bio‑OS). It specifies the verb (upload/import) and resource (WDL workflows), and mentions support for single files or entire directories. However, it doesn't explicitly differentiate from sibling tools like 'upload_dashboard_file' or 'fetch_wdl_from_dockstore', which prevents a score of 5.
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. There's no mention of prerequisites, when not to use it, or how it relates to sibling tools like 'validate_wdl', 'submit_workflow', or 'check_workflow_import_status'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates workflow input JSON, implying a read-only check, but doesn't describe what validation entails (e.g., syntax checks, schema compliance, error reporting), whether it modifies data, requires authentication, or has rate limits. The description is minimal and lacks critical behavioral details for a tool with no 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 a single, efficient sentence in Chinese that directly states the tool's function. It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration. This makes it highly concise and well-structured for quick comprehension.
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 moderate complexity (validating JSON with dependencies on WDL and input files), no annotations, and an output schema present, the description is minimally complete. It identifies the tool's purpose but lacks details on behavior, usage context, or parameter roles. The output schema likely covers return values, reducing the need for that in the description, but overall, the description is adequate with clear gaps in guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, but the schema itself includes descriptions for parameters like 'wdl_path' and 'input_json'. The description doesn't explain these parameters or their roles in validation. With one parameter object and schema doing the work, the baseline score of 3 is appropriate, as the description doesn't compensate for the coverage gap but doesn't hinder understanding either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '验证工作流输入 JSON 文件' (Validate workflow input JSON file) states the tool's purpose as validating workflow input JSON, which is clear but vague. It specifies the action (validate) and resource (workflow input JSON file), but doesn't distinguish it from sibling tools like 'validate_wdl' or explain what validation entails. The purpose is understandable but lacks specificity about scope or differentiation.
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 doesn't mention prerequisites (e.g., needing a WDL file or input JSON), exclusions, or related tools like 'validate_wdl' or 'compose_input_json'. Usage is implied only by the tool's name and description, with no explicit context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('查看' meaning 'check/view'), but doesn't disclose authentication needs (though the schema hints at ak/sk), rate limits, error conditions, or what the status output entails (e.g., pending, running, failed). This leaves significant gaps for safe and effective use.
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 in Chinese that directly states the tool's purpose without fluff. It's appropriately front-loaded with the core action and target. However, it could be slightly more structured by explicitly naming the parameters or adding a brief context sentence.
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 moderate complexity (checking status of a resource), no annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It states what the tool does but lacks context on authentication, error handling, or typical workflows. The output schema may cover return values, but the description doesn't guide the agent on interpreting results or integration with siblings like 'create_iesapp'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter semantics beyond implying 'workspace' and 'IES instance' are required. It doesn't explain the 'cfg' object structure, the purpose of ak/sk/endpoint fields, or format expectations (e.g., string patterns). With 1 parameter (a nested object with 5 sub-parameters), the baseline is 3 as the schema lacks descriptions, but the tool description doesn't compensate meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('查看' meaning 'check/view') and the target resource ('指定workspace中的指定IES实例的创建状态' meaning 'specified IES instance creation status in a specified workspace'). It distinguishes from siblings like 'get_ies_events' or 'check_build_status' by focusing specifically on creation status. However, it doesn't explicitly mention what 'IES' stands for or the broader context, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_ies_events' or 'check_build_status'. It doesn't mention prerequisites (e.g., needing an existing workspace/IES instance) or typical use cases (e.g., monitoring after 'create_iesapp'). The agent must infer usage from the tool name and sibling context alone.
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 but offers minimal information. It states the tool generates a file but doesn't describe what happens if the file already exists, whether this is a read or write operation, what permissions are needed, or what the output looks like. For a file generation tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 Chinese characters, with no wasted words. It's front-loaded with the core purpose and contains no unnecessary elaboration. While it may be too brief for complete understanding, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested object with 4 required parameters), no annotations, and the presence of an output schema, the description is inadequate. It doesn't explain the relationship between template JSON and generated output, the sample count validation mentioned in the schema, or how this tool fits into the broader workflow context with sibling tools. The output schema helps but doesn't compensate for the minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions '用户给的数值' (user-provided values) which loosely corresponds to the 'params' parameter in the schema, but provides no specifics about parameter structure or usage. With 0% schema description coverage, the description doesn't adequately compensate by explaining the complex nested 'cfg' parameter containing template paths, output paths, sample counts, and parameter data. The baseline is 3 since schema coverage is low but the description adds minimal value.
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 '根据用户给的数值生成input.json' clearly states the tool's purpose: generating an input.json file from user-provided values. It specifies both the action (生成/generate) and the resource (input.json). However, it doesn't differentiate from sibling tools like 'generate_inputs_json_template_bioos' or explain how this differs from other JSON generation tools in the server.
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. There's no mention of prerequisites, when this tool is appropriate, or when to choose sibling tools like 'generate_inputs_json_template_bioos' or 'validate_workflow_input_json'. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '删除' (delete) implies a destructive mutation, but the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or what happens to associated resources. It also doesn't mention rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese that communicates the core purpose without any wasted words. It's appropriately sized for a simple deletion operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, 0% schema description coverage, and no parameter guidance in the description, this is incomplete. While an output schema exists (which helps with return values), the description fails to address critical behavioral aspects like permanence, permissions, or error handling that are essential for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter descriptions are entirely missing from the schema. The tool description provides no parameter information whatsoever, not even mentioning the required 'cfg' object or its nested fields like 'workspace_name' and 'submission_id'. However, with only 1 top-level parameter (the cfg object), the baseline is 3 since the agent can infer this is a configuration object.
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 'Bio-OS 删除工作流提交' clearly states the action (删除/delete) and resource (工作流提交/workflow submission) in Chinese, making the purpose immediately understandable. It doesn't differentiate from siblings like 'check_workflow_run_status' or 'get_workflow_logs', but the verb+resource combination is specific enough for basic understanding.
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. There's no mention of prerequisites (e.g., needing an existing submission), consequences of deletion, or when to choose this over other submission-related tools like 'check_workflow_run_status' or 'get_workflow_logs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions querying and generating a template, it lacks critical details: whether this is a read-only operation, if it requires authentication (implied by ak/sk parameters but not stated), potential rate limits, or what the generated template looks like. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core action in a single sentence. There's no wasted text, and it efficiently conveys the tool's primary function. However, the lack of additional context or structure (e.g., bullet points for key points) slightly limits its effectiveness, though it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves querying and generating templates for workflows), the absence of annotations, and the presence of an output schema, the description is minimally adequate. It states what the tool does but misses behavioral context (e.g., authentication needs, error handling). The output schema likely covers return values, so the description doesn't need to explain those, but it should address usage scenarios and prerequisites more clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage, the schema itself documents all parameters (workspace_name, workflow_name, ak, sk, endpoint) thoroughly. The description doesn't explain what 'cfg' contains or how parameters interact, but since the schema covers everything adequately, the baseline score of 3 is appropriate.
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's purpose: '查询' (query) and '生成' (generate) an inputs.json template for a Bio-OS workflow. It specifies the resource (Bio-OS workflow) and the output (input parameter template). However, it doesn't explicitly differentiate from sibling tools like 'compose_input_json' or 'validate_workflow_input_json', which may have overlapping functions.
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 minimal guidance on when to use this tool. It implies usage for workflows already imported into Bio-OS, but offers no explicit when/when-not scenarios or alternatives. For example, it doesn't clarify if this should be used instead of 'compose_input_json' or in conjunction with 'validate_workflow_input_json', leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation, which implies read-only behavior, but doesn't disclose authentication requirements (though the schema shows ak/sk parameters), rate limits, pagination behavior (schema mentions page_size but description doesn't explain it), or what happens when no workspaces exist. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that states the core purpose without unnecessary words. It's appropriately sized for a simple listing tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a read operation with an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a tool with authentication parameters and pagination options, the description should at least mention these aspects. The combination of no annotations, 0% schema description coverage, and a sparse description leaves significant gaps in understanding how to use this tool effectively.
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 for undocumented parameters. The description mentions no parameters at all, while the schema shows one required 'config' parameter with four sub-properties (ak, sk, endpoint, page_size). The description fails to explain what these parameters do, when they're needed, or how they affect the listing operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('列出' - list) and resource ('工作空间名称与描述' - workspace names and descriptions) with the scope '当前登录环境' (current login environment). It's specific about what information is returned (names and descriptions), but doesn't differentiate from potential sibling tools like 'create_workspace_bioos' or 'export_bioos_workspace'.
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. There's no mention of prerequisites, when this tool is appropriate versus other workspace-related tools, or any exclusions. The context '当前登录环境' (current login environment) is the only contextual hint.
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 it 'checks' status, implying a read-only operation, but doesn't disclose behavioral traits such as required permissions, rate limits, response format (though output schema exists), or whether it polls or returns cached data. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy 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?
Given the tool's moderate complexity (status checking), no annotations, and an output schema (which handles return values), the description is minimally complete. It states what the tool does but lacks context on usage, behavioral details, and parameter meaning, leaving gaps that could hinder effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the input schema, which has 0% description coverage. With one parameter ('task_id'), the schema provides the title and type, but the description doesn't explain what 'task_id' represents (e.g., from a previous build operation) or its format. Baseline is 3 due to high schema coverage (100% for the single parameter), but the description doesn't compensate for the lack of semantic details.
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 '检查 Docker 镜像构建状态' (Check Docker image build status) clearly states the verb ('检查' - check) and resource ('Docker 镜像构建状态' - Docker image build status). It distinguishes from siblings like 'build_docker_image' (which creates) and 'get_docker_image_url' (which retrieves URL), but doesn't explicitly differentiate from other 'check_' tools (e.g., 'check_ies_status').
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 doesn't mention prerequisites (e.g., after initiating a build), exclusions, or relationships with siblings like 'build_docker_image' (which might trigger the build) or 'get_ies_events' (which might show related events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('查看' - view) without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, or what the output contains. The description is minimal and lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy 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?
Given the tool's moderate complexity (5 nested parameters, no annotations, but has an output schema), the description is incomplete. It states the purpose but lacks usage guidelines, behavioral details, and parameter explanations. The output schema may cover return values, but the description doesn't provide enough context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal semantic context by implying parameters for 'workspace' and 'IES instance'. However, it doesn't detail the 'cfg' parameter structure or explain the five nested parameters (ak, sk, workspace_name, endpoint, ies_name) beyond what the schema titles provide. The description partially compensates but leaves significant gaps.
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 '查看指定workspace中的指定IES实例的创建日志' clearly states the action ('查看' - view) and resource ('IES实例的创建日志' - IES instance creation logs) with specific scope ('指定workspace中的指定IES实例' - in a specified workspace and IES instance). It distinguishes from siblings like 'check_ies_status' (status check) and 'get_workflow_logs' (workflow logs), but doesn't explicitly contrast 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 on when to use this tool versus alternatives is provided. The description implies usage for viewing creation logs of a specific IES instance in a workspace, but doesn't mention prerequisites, when not to use it, or compare with siblings like 'check_ies_status' for general status or 'get_workflow_logs' for workflow-specific logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool uploads a file to S3, implying a write operation, but lacks details on permissions required, whether it overwrites existing files, error handling, rate limits, or authentication needs (though the input schema hints at credentials). This leaves behavioral traits largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy 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?
Given the tool's complexity (file upload to S3 with credentials and workspace context), no annotations, and an output schema present (which likely covers return values), the description is minimally adequate. It states what the tool does but lacks behavioral details and usage context, leaving gaps in completeness for an upload operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions '指定工作空间' (specified workspace) and implies a file upload, but doesn't detail parameters beyond that. With 0% schema description coverage, the input schema fully documents the single parameter 'cfg' and its nested properties (e.g., workspace_name, local_file_path, credentials). The description adds minimal value over the schema, so baseline 3 is appropriate as the schema handles most semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('上传' meaning 'upload') and the resource ('__dashboard__.md文件' meaning '__dashboard__.md file') with the destination ('指定工作空间的S3桶' meaning 'specified workspace's S3 bucket'). It's specific about what gets uploaded and where, though it doesn't explicitly differentiate from sibling tools like 'export_bioos_workspace' or 'import_workflow' which might involve file operations.
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 doesn't mention prerequisites (e.g., needing a workspace or file), exclusions, or compare to sibling tools like 'export_bioos_workspace' for downloading or 'import_workflow' for other file imports. Usage is implied only by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool validates syntax but doesn't describe what happens during validation - whether it's read-only, what permissions are needed, what errors might be returned, or how results are presented. For a validation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's purpose. There's zero wasted language, and the information is front-loaded with no unnecessary elaboration. This is optimal conciseness for a simple validation 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?
Given the tool has an output schema (which should document return values), the description doesn't need to explain outputs. However, for a validation tool with no annotations and 0% schema description coverage, the description should do more to explain what 'syntax validation' entails, what standards are checked, and typical use cases. It's minimally adequate but leaves important context implicit.
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 schema provides no parameter descriptions. The tool description doesn't mention any parameters at all, failing to compensate for the schema gap. However, with only 1 parameter (wdl_path), the agent can reasonably infer it's a file path for validation. Baseline 3 reflects minimal viability given single parameter simplicity.
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 '验证 WDL 文件的语法正确性' clearly states the action (validate) and resource (WDL file syntax correctness). It's specific about what validation is performed (syntax checking). However, it doesn't differentiate from sibling tools like 'validate_workflow_input_json' which validates different aspects of workflow files.
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. There's no mention of prerequisites, when validation should occur in a workflow lifecycle, or how this differs from other validation tools in the sibling list. The agent must infer usage context from the tool name alone.
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:

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

Score Badge

Copy to your README.md:

[![bioos-mcp-server MCP server](https://glama.ai/mcp/servers/GBA-BI/bioos-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/GBA-BI/bioos-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GBA-BI/bioos-mcp-server'

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