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 script.py를 실행하는 것처럼 전체 YADE 스크립트를 백그라운드 작업으로 실행하세요. 단, 계속 지켜볼 필요는 없습니다. 에이전트가 스스로 실시간 출력을 추적하고, 오류 발생 시 포착하며, 문제가 보이면 안전하게 실행을 중단하고, 스크립트를 수정하여 시뮬레이션이 완료될 때까지 다시 제출합니다.
yade_list_tasks + yade_check_task_status 기반
제출한 모든 작업(스크립트, 실시간 출력, 최종 상태)이 기록으로 남습니다. 컨텍스트 창이 가득 차거나 다음 날 다시 돌아왔을 때, 새로운 에이전트가 이미 스스로를 기억하는 프로젝트에 투입됩니다. 에이전트는 무엇이 실행되었는지 나열하고, 각 작업의 결과를 읽으며, 사용자가 다시 설명할 필요 없이 작업을 이어받습니다.
yade_execute_code 기반
작업이 실행되는 동안 에이전트는 시뮬레이션에 대한 실시간 셸을 가집니다. 스크립트를 수정하거나 실행을 중단할 필요 없이, 변수 검사, 객체 상태 덤프, 새로운 플롯 생성 등을 요청할 수 있습니다.
제출된 작업 외에도, 사용자가 YADE 콘솔에 입력하는 모든 내용(확인한 변수, 테스트한 매개변수, 시도하다 중단한 작업 등)이 에이전트의 컨텍스트로 전달됩니다. 대화를 시작하면 에이전트는 이미 사용자가 무엇을 시도했는지 파악하고 있습니다. YADE를 배우는 중이며 방금 입력한 내용에 대한 피드백이 필요한가요? 예상치 못한 오류로 막혔나요? 그냥 물어보세요. 에이전트는 사용자가 무엇을 입력했고 YADE가 어떻게 응답했는지 알고 있습니다.
Related MCP server: itasca-mcp
두 개의 문서 도구(브리지 불필요)와 다섯 개의 실행 도구(브리지 필요):
도구 | 목적 | 브리지 |
| YADE 파이썬 클래스 트리 탐색 | 아니오 |
| API 전체에 대한 BM25 키워드 검색 | 아니오 |
| 실시간 YADE 프로세스에서 파이썬 실행; 동기식 반환 | 예 |
| 스크립트를 장기 실행 백그라운드 작업으로 제출 | 예 |
| 실행 중이거나 완료된 작업 검사 (출력, 상태) | 예 |
| 실행 중인 작업을 안전하게 중단 | 예 |
| 제출된 작업을 메타데이터와 함께 나열 | 예 |
이를 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 파이썬 콘솔에서:
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.
