yade-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| yade_browse_apiA | Browse YADE's Python API as a YADE-native class tree. The tree is rooted in YADE's real inheritance hierarchy: paths mirror the class's mro up to its category root. No shortcuts — always drill through parents. |
| yade_query_apiA | Search YADE API documentation by keywords (like grep). Returns matching class/function names with descriptions ranked by relevance. Use yade_browse_api for full documentation of a specific class. When to use:
Related tools:
|
| yade_execute_taskA | 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:
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(). |
| yade_check_task_statusC | Check status and output for a submitted YADE task. |
| yade_list_tasksA | List tracked YADE tasks with pagination. Tasks are listed newest first. Queued (pending) tasks run one at a time in submit order, so among the pending entries the one furthest down the list runs next. |
| yade_interrupt_taskA | Stop a running YADE task, or cancel one still waiting in the queue. A task that has not started yet is simply removed from the queue
and ends in status
The response Namespace after interrupt: the YADE |
| yade_execute_codeA | Execute Python code synchronously in the running YADE process. Returns stdout immediately. Code runs in the YADE Python environment where yade modules are already imported; side effects persist. This tool remains responsive EVEN WHILE a simulation task is running (submitted via yade_execute_task). Use it as a live REPL to inspect simulation state in real time — no need to pre-script print statements. Typical uses:
O.engines[0] holds a PyRunner that belongs to yade-mcp-bridge (its command mentions "mcp bridge"). Ignore it: assign O.engines as usual, the bridge re-adds the PyRunner before every O.run(). Unlike yade_execute_task, this tool is fire-and-return: the response contains the full output. It is NOT tracked by yade_list_tasks and cannot be interrupted or polled. Timeout behaviour: on timeout the bridge attempts to abort the
running code. The response is an error envelope (
WARNING: For anything expected to take more than a few seconds,
use yade_execute_task instead — it has proper cancellation via
yade_interrupt_task and does not leave state drift on timeout.
Also, do NOT write |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
The task lifecycle tools, synchronous code execution, and API discovery tools are mostly distinct. The only likely point of confusion is yade_execute_task vs yade_execute_code, but their descriptions clearly separate async tracked production runs from synchronous REPL-style use.
All tools use a consistent yade_ prefix with snake_case verb_noun naming: list_tasks, execute_task, check_task_status, interrupt_task, execute_code, browse_api, query_api. The pattern is predictable throughout.
Seven tools is well-scoped for this server: four task-lifecycle tools, one synchronous execution tool, and two API discovery tools. Each tool has a clear role and the set does not feel bloated or thin.
The core surface is covered: async and sync execution, task listing/status/interrupt, and API browsing/search. Minor lifecycle gaps remain, such as no explicit task deletion/cleanup or separate wait/get-task tool, though yade_check_task_status covers output and final status.