O.engines += [LLM()] # 又一个引擎。
yade-mcp 通过 模型上下文协议 (Model Context Protocol) 将 AI 智能体连接到 YADE（开源离散元方法引擎）。通过自然对话即可浏览 API 文档、运行模拟并执行代码。
你的智能体不仅仅是调用工具，它就像坐在你的 YADE 控制台前，能够独立运行长时间的模拟，并与你的操作保持同步。
由 yade_execute_code 驱动
用通俗的语言描述你的需求。智能体会在你的 YADE 控制台中输入命令——检查颗粒、调整参数、单步执行引擎、分析结果。它会像你亲自操作控制台一样，读取每次输出、调试并进行迭代。
由 yade_execute_task + yade_check_task_status + yade_interrupt_task 驱动
将完整的 YADE 脚本作为后台任务运行——就像执行 yade script.py 一样，但你无需时刻盯着它。智能体会自动监控：跟踪实时输出、捕获出现的错误、在发现异常时优雅地停止运行、修复脚本并重新提交——直到模拟真正完成。
由 yade_list_tasks + yade_check_task_status 驱动
你提交的每一个任务——脚本、实时输出、最终状态——都会被记录下来。当上下文窗口填满或你第二天回来时，新的智能体会进入一个已经“自我记忆”的项目：它会列出已运行的任务，读取每个任务的产出，并在无需你重新解释的情况下继续工作。
由 yade_execute_code 驱动
当任务运行时，智能体拥有一个进入模拟的实时 Shell——你可以要求它检查任何变量、转储任何对象的状态，或按需渲染新的绘图，而无需编辑脚本或停止运行。
除了提交的任务外，你在 YADE 控制台中输入的每一行内容——你查看的变量、测试的参数、尝试过的死胡同——也会流入智能体的上下文中。当你转而进行对话时，它已经掌握了你尝试过的路径。正在学习 YADE 并希望对刚才输入的内容获得反馈？被意外的错误困住了？直接问它——智能体看到了你输入的内容以及 YADE 的回答。
Related MCP server: itasca-mcp
包含两个文档工具（无需桥接）和五个执行工具（需要桥接）：
工具 | 用途 | 桥接 |
| 遍历 YADE Python 类树 | 否 |
| 对 API 进行 BM25 关键词搜索 | 否 |
| 在实时 YADE 进程中运行 Python；同步返回 | 是 |
| 将脚本作为长时间运行的后台任务提交 | 是 |
| 检查运行中或已完成的任务（输出、状态） | 是 |
| 优雅地停止运行中的任务 | 是 |
| 列出已提交的任务及其元数据 | 是 |
将其复制到你的 AI 智能体中，让它自动配置：
Fetch and follow this bootstrap guide end-to-end:
https://raw.githubusercontent.com/yusong652/yade-mcp/master/docs/agentic/yade-mcp-bootstrap.md1. 在你的客户端配置中注册 MCP 服务器：
{
"mcpServers": {
"yade-mcp": {
"command": "uvx",
"args": ["yade-mcp"]
}
}
}2. 在 YADE 内部启动桥接：
pip install yade-mcp-bridge然后在 YADE Python 控制台中：
import yade_mcp_bridge
yade_mcp_bridge.start()重启你的 AI 智能体（Claude Code、Codex CLI、Gemini CLI 等），并要求它调用 yade_execute_code 以验证连接。
请参阅 CONTRIBUTING.md 获取开发设置和指南。
MIT — 请参阅 LICENSE。
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Dot-separated path into YADE's class hierarchy. Navigation is tree-driven (no class-name shortcuts). - None or '': list top-level categories (engine / functor / material / shape / ...) - 'engine': list direct sub-trees of Engine (Dispatcher, GlobalEngine, PartialEngine, ...) - 'engine.GlobalEngine': list GlobalEngine's sub-trees (BoundaryController, Collider, PeriodicEngine, ...) plus its direct leaf classes (NewtonIntegrator, InteractionLoop, ...) - 'engine.GlobalEngine.NewtonIntegrator': full docs for NewtonIntegrator - 'functor.LawFunctor.Law2_ScGeom_FrictPhys_CundallStrack': full docs for a contact law functor Every leaf is reached via its parent-class chain. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'no shortcuts' and 'always drill through parents,' which is a behavioral constraint. As a browse tool, it is implicitly read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two informative sentences. It is front-loaded with the main purpose. Could include a bit more detail, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, browse-only) and the presence of an output schema, the description is complete enough. It explains the hierarchy and navigation rules. Minor omission: does not mention the response format, but output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already provides detailed parameter semantics with examples. The tool description adds context about the tree structure, but the parameter description in the schema is sufficiently rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses YADE's Python API as a class tree, and the parameter description further clarifies navigation. It is distinct from sibling tools which are task/execution related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. However, the siblings are clearly different in function, so the context provides implicit usage guidance. No exclusions or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check status and output for a submitted YADE task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Output lines per page | |
| filter | No | Only keep output lines containing this text | |
| task_id | Yes | Task ID returned by yade_execute_task | |
| skip_newest | No | Skip N newest output lines before pagination | |
| wait_seconds | No | Delay before querying (prevents polling too fast). Use 0 for immediate check. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It merely states the tool checks status and output, but does not explain that it performs a polling operation (as suggested by wait_seconds parameter), whether it waits for completion, or what the output format entails. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It is front-loaded with the core action. However, it could be slightly longer to include essential usage context without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex input schema with 5 parameters and an existing output schema, the description provides minimal context. It fails to explain the tool's role in the workflow (e.g., polling for task completion), the meaning of the output, or how parameters like wait_seconds affect behavior. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what is already in the input schema. While adequate, it does not enhance understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Check' and specific resource 'status and output for a submitted YADE task'. It distinguishes from sibling tools like yade_execute_task (submission) and yade_interrupt_task (interruption), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after submitting a YADE task ('for a submitted YADE task'), but it does not explicitly specify when to use this tool versus alternatives like yade_list_tasks or yade_interrupt_task, nor does it provide any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Query simulation state: O.bodies count, current iteration
Create/modify bodies, engines, interactions
Read or set material properties
Live inspection during a running simulation (e.g. check stress tensor, coordination number, energy balance, or capture viewport screenshots when GUI is available)
Development and REPL-style testing
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 (ok=false)
whose error.code is one of:
interrupted — the code was running a simulation cycle
(O.run) and was paused cleanly at an iteration boundary.
For long simulations or solving to equilibrium, switch to
yade_execute_task — it tracks progress and stops cleanly via
yade_interrupt_task.
terminated — a non-cycle abort succeeded (async exception
injection); the pump thread is free, but YADE state may be
partially modified by the code that ran before the abort fired.
Inspect state before retrying.
timeout — abort failed (code stuck in a C extension, or
nested inside a running task's PyRunner tick); the bridge may
still be blocked. Restart if unresponsive.
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 except BaseException: in your code; it
defeats bridge-initiated cancellation.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python code to execute in YADE process | |
| timeout | No | Console execution timeout in seconds |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Details side effects persistence, responsiveness during running simulations, timeout error codes (interrupted, terminated, timeout), and consequences of each. Also warns about state drift and unresponsiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded core purpose, bullet points for typical uses, and detailed timeout section. Every sentence adds value, though length could be slightly reduced for extreme conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: what, when, alternatives, side effects, error handling, and warnings. Output schema exists but is not needed since tool behavior is fully described. Complete for a synchronous execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context about timeout behavior (error codes, suggestions) but does not significantly expand parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes Python code synchronously in the YADE process and returns stdout immediately. It explicitly contrasts with yade_execute_task for long-running simulations, establishing a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for quick REPL-style inspection, not for tasks > a few seconds (use yade_execute_task). Warns against catching BaseException to avoid breaking cancellation. Includes alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Brief task purpose | |
| script_path | Yes | Absolute path to entry Python script for YADE |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details asynchronous execution, immediate return, background queuing, and sequential ordering. No annotations provided, so the description carries full burden and does well, though it omits potential failure modes or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: tool purpose first, then behavior, companion tools, and usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, queue, lifecycle), the description covers the key aspects: single-threaded execution, queue ordering, companion tools, and use case differentiation. Presence of output schema (context) covers return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context: script_path is absolute, description is 'brief task purpose'. This enhances understanding beyond the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a Python script for asynchronous execution, returns a task_id, and distinguishes itself from sibling tools like yade_execute_code by specifying use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use for production runs and long operations, and advises using yade_execute_code for quick testing. Also explains the sequential queue behavior and lifecycle management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 canceled (method reports
canceled_while_queued). For a running task, two cancellation
paths are applied together by the bridge:
flag_only — sets an interrupt flag that YADE's PyRunner
tick observes between simulation iterations (graceful path
for O.run tasks).
flag_and_async_exc — in addition, injects a TaskInterrupt
exception into the script thread, so pure-Python deadloops
with no O.run on the stack are terminated too.
The response method field reports which path ran. When
async-exc is refused (e.g. target thread is a Dummy-N
boost::python frame), async_exc_skipped_reason explains why.
Namespace after interrupt: the YADE __main__ namespace is
shared between tasks and yade_execute_code calls. Any
variables the interrupted script had already defined —
including O state — are preserved. There's no need to
re-run the whole script to continue work: inspect state with
yade_execute_code or resume via a fresh yade_execute_task
that only runs the remaining logic.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID returned by yade_execute_task |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: cancellation paths (flag_only, flag_and_async_exc), response method field, namespace preservation, and async exception handling. Very transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, but subsequent paragraphs contain detailed technical explanations. While informative, some sentences could be condensed. Still well-structured for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers task states, cancellation paths, namespace impact, and response details. Given the tool's complexity and presence of an output schema, the description is thorough and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds context: 'Task ID returned by yade_execute_task'. While schema already describes the parameter, the description clarifies its source and usage, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Stop a running YADE task, or cancel one still waiting in the queue.' Specific verb and resource, distinct from sibling tools like yade_execute_task or yade_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides when to use (interrupt/cancel tasks) and explicitly references alternatives for inspecting state (yade_execute_code) and resuming (yade_execute_task), offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max tasks to return | |
| skip_newest | No | Skip N most recent tasks before listing |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering ('newest first') and queue behavior for pending tasks, adding value beyond the schema. However, with no annotations, it could further state that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each valuable. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description sufficiently covers listing, pagination, and ordering. Minor gap: no mention of return fields, but schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context about pagination ordering but no new meaning beyond param descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List tracked YADE tasks with pagination' with a specific verb and resource, and implicitly distinguishes from sibling tools like yade_check_task_status by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., yade_check_task_status), nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
You have keywords but don't know the exact class name
Examples: "friction material", "gravity engine", "contact force", "triaxial stress", "sphere create", "hertz mindlin"
Related tools:
yade_browse_api: Get full documentation for a known class path
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-20). | |
| query | Yes | Search keywords for YADE Python API. Examples: 'sphere body', 'triaxial compression', 'contact force'. Case-insensitive. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool returns ranked search results, implying a read-only operation. While it does not explicitly declare no side effects, the nature of a documentation search tool makes this clear. The description could be slightly more explicit about being non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the primary action, then describes return values, then provides usage guidance with examples, and finally lists a related tool. Every sentence is informative and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown, but indicated), the description does not need to detail return format. It covers purpose, usage scenarios, concrete query examples, and sibling tool differentiation. It is complete for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing example queries (e.g., 'sphere body') and the analogy 'like grep', which helps the agent understand how to formulate the query. This enriches the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches YADE API documentation by keywords, likening it to grep. It specifies that it returns class/function names with descriptions ranked by relevance. This differentiates it from the sibling yade_browse_api, which provides full documentation for a known class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'When to use' section with concrete examples (e.g., 'friction material', 'gravity engine'). It also tells when to use the alternative tool (yade_browse_api for full documentation of a specific class). This provides clear guidance for the agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.3yade_execute_task3 fields changedInput schema / properties / entry_scriptRemoved value: -{
- "description": "Absolute path to entry Python script for YADE",
- "type": "string"
-}Input schema / properties / script_pathAdded value: +{
+ "description": "Absolute path to entry Python script for YADE",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "entry_script",
- "description"
-]New value: +[
+ "script_path",
+ "description"
+]yade_browse_api1 field changedInput schema / properties / path / descriptionPrevious value: -"Dot-separated API path to browse. Progressive disclosure:\n- None or '': Root — list all categories\n- 'engines': List all engine classes\n- 'engines.NewtonIntegrator': Full docs for NewtonIntegrator\n- 'materials': List all material classes\n- 'materials.FrictMat': Full docs for FrictMat\n- 'interactions.geometry': List contact geometry classes\n- 'interactions.laws.Law2_ScGeom_FrictPhys_CundallStrack': Full docs\n- 'utils': Utility functions\n- 'omega': Omega (O) simulation control"New value: +"Dot-separated path into YADE's class hierarchy. Navigation is tree-driven (no class-name shortcuts).\n- None or '': list top-level categories (engine / functor / material / shape / ...)\n- 'engine': list direct sub-trees of Engine (Dispatcher, GlobalEngine, PartialEngine, ...)\n- 'engine.GlobalEngine': list GlobalEngine's sub-trees (BoundaryController, Collider, PeriodicEngine, ...) plus its direct leaf classes (NewtonIntegrator, InteractionLoop, ...)\n- 'engine.GlobalEngine.NewtonIntegrator': full docs for NewtonIntegrator\n- 'functor.LawFunctor.Law2_ScGeom_FrictPhys_CundallStrack': full docs for a contact law functor\nEvery leaf is reached via its parent-class chain."yade_check_task_status2 fields changedInput schema / properties / wait_seconds / descriptionPrevious value: -"Wait time before querying status"New value: +"Delay before querying (prevents polling too fast). Use 0 for immediate check."Input schema / properties / wait_seconds / minimumPrevious value: -1New value: +0v0.1.0yade_browse_apiyade_check_task_statusyade_execute_codeyade_execute_taskyade_interrupt_taskyade_list_tasksyade_query_apiScored across 7 tools
Each tool has a clear, distinct purpose: API browsing and searching are separate from code execution (sync vs async) and task management (status, interrupt, list). No overlap in functionality, and descriptions explicitly differentiate borderline cases (e.g., execute_code vs execute_task).
All tools follow a consistent 'yade_verb_noun' pattern in snake_case. Verbs are descriptive (browse, check, execute, interrupt, list, query) and nouns are specific (api, task, code, tasks). No mixing of styles.
With 7 tools, the surface is well-scoped for YADE interaction: API exploration (2 tools), code execution (2 tools for synchronous vs async), and task lifecycle management (3 tools). Not too many or too few.
The toolset covers the full lifecycle of interacting with a YADE simulation: discovering API, executing code synchronously for quick queries and asynchronously for long tasks, managing task queue (submit, interrupt, list, check status). No obvious gaps.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
Let AI agents query data and act across all your business apps via MCP.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
