Skip to main content
Glama
Sign In
yusong652

yade-mcp

by yusong652
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

yade_execute_task

Submit a Python script for asynchronous background execution in YADE and get a task_id immediately, so long simulation runs and multi-stage pipelines queue and complete without blocking your session.

Instructions

Submit a Python script for asynchronous execution in YADE.

Returns a task_id immediately; the script is queued and runs in the background. Tasks run one at a time in submit order (they share the YADE process and its single simulation state), so a multi-stage pipeline can be submitted in one go — each stage starts when the previous one finishes. Use the companion tools to manage the task lifecycle:

  • yade_check_task_status: poll output, progress, and final status

  • yade_interrupt_task: stop a running task or cancel a queued one

  • yade_list_tasks: browse task history (also shows queue order)

Use this for production simulation runs, long O.run() cycles, and any operation that may take minutes or longer. For quick queries and REPL-style testing, use yade_execute_code.

O.engines[0] holds a PyRunner that belongs to yade-mcp-bridge (its command mentions "mcp bridge"). The script does not need to keep it: assign O.engines as usual, the bridge re-adds the PyRunner before every O.run().

Input Schema

NameRequiredDescriptionDefault
descriptionYesBrief task purpose
script_pathYesAbsolute path to entry Python script for YADE

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.3
    • removedInput schema / properties / entry_script
      Removed value: -{
-  "description": "Absolute path to entry Python script for YADE",
-  "type": "string"
-}
    • addedInput schema / properties / script_path
      Added value: +{
+  "description": "Absolute path to entry Python script for YADE",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "entry_script",
-  "description"
-]New value: +[
+  "script_path",
+  "description"
+]
  2. First observedv0.1.0

TDQS

A4.7/5.0
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 and does so well: it discloses immediate task_id return, background queuing, single-task-at-a-time execution, submit-order pipeline behavior, shared single simulation state, and the special PyRunner bridge behavior before every O.run(). These are exactly the behavioral traits an agent needs before invoking an asynchronous task.

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 its length, the description is well structured and front-loaded: the core submit-and-return behavior comes first, followed by queue semantics, lifecycle routing, usage distinction, and the bridge detail. Each paragraph or bullet provides actionable information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is inherently complex because it is asynchronous and stateful, and the description covers the critical execution model, ordering guarantees, lifecycle delegation, and usage boundaries. An output schema exists, so return-value details are not required in the 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds context about the script being an entry point but does not explain parameter format or semantics beyond what the schema provides, so the baseline 3 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 states a specific verb and resource ('Submit a Python script for asynchronous execution in YADE') and explicitly distinguishes the tool from yade_execute_code for quick REPL-style use. It also names the lifecycle companion tools, so an agent can place it immediately among siblings.

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?

It gives explicit when-to-use guidance ('production simulation runs, long O.run() cycles, and any operation that may take minutes or longer') and an explicit alternative for quick work ('use yade_execute_code'). The lifecycle section further routes the agent to status, interrupt, and list tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools