O.engines += [LLM()] # yet another engine.
yade-mcp は、YADE（オープンソースの離散要素法エンジン）と AI エージェントを Model Context Protocol を介して接続します。自然な会話を通じて、API ドキュメントの閲覧、シミュレーションの実行、コードの実行が可能です。
エージェントは単にツールを呼び出すだけでなく、YADE コンソールに常駐し、独自の判断で長時間シミュレーションを実行し、ユーザーの作業と同期を保ちます。
Powered by yade_execute_code
やりたいことを自然言語で記述します。エージェントは YADE コンソールにコマンドを入力し、粒子の検査、パラメータの調整、エンジンのステップ実行、結果の分析を行います。エージェントは各出力を読み取り、デバッグし、反復処理を行います。これはユーザー自身がコンソールで行う作業と同じです。
Powered by yade_execute_task + yade_check_task_status + yade_interrupt_task
yade script.py を実行するのと同様に、完全な YADE スクリプトをバックグラウンドタスクとして実行します。ただし、付きっきりである必要はありません。エージェントが自律的に監視を行い、ライブ出力を追跡し、エラーが発生すれば捕捉し、異常があれば適切に実行を停止し、スクリプトを修正して再実行します。シミュレーションが完了するまでこれを行います。
Powered by yade_list_tasks + yade_check_task_status
送信したすべてのタスク（スクリプト、ライブ出力、最終状態）は記録として残ります。コンテキストウィンドウがいっぱいになったり、翌日作業を再開したりする場合でも、新しいエージェントがプロジェクトに加われば、以前の状態を記憶しています。何が実行されたかをリストアップし、各タスクの生成物を読み取り、説明を繰り返すことなく作業を再開できます。
Powered by yade_execute_code
タスクの実行中、エージェントはシミュレーションへのライブシェルを持ちます。スクリプトを編集したり実行を停止したりすることなく、変数の検査、オブジェクト状態のダンプ、新しいプロットの生成などを要求できます。
送信されたタスクだけでなく、YADE コンソールに入力したすべての行（確認した変数、テストしたパラメータ、行き詰まった試行など）もエージェントのコンテキストに流し込まれます。チャットに切り替えたとき、エージェントはすでにユーザーが何を試みていたかの軌跡を把握しています。YADE を学習中で入力内容に対するフィードバックが欲しい場合や、予期せぬエラーで詰まった場合でも、エージェントはユーザーの入力と YADE の応答を把握しているため、すぐに質問できます。
Related MCP server: itasca-mcp
2 つのドキュメントツール（ブリッジ不要）と 5 つの実行ツール（ブリッジが必要）があります：
ツール | 目的 | ブリッジ |
| 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.
