The server lets Claude Desktop delegate quant coding tasks to an AI agent (Pi or smolagents) that writes, runs, and debugs Python using your existing library functions, then returns structured results and artifacts.
run_quant_coding_task(prompt, timeout_seconds=300): Submit a natural-language quant task (e.g., pricing options, P&L calculations). The agent reads your registered modules and examples, writes Python, executes it, validates output, and repairs on failure.
analyze_option_portfolio(prompt, timeout_seconds=120): Backward-compatible entry point for option-related tasks; prefer run_quant_coding_task.
list_artifacts(): List recent task IDs and their saved artifacts.
read_artifact(task_id, filename): Read text artifacts (e.g., result.json, analysis.py, run.log) or get the path for binary files like xlsx.
Automated execution: No interactive review; the system loops until a validated successful run, then saves artifacts (prompt, agent instructions, library catalog, generated code, logs, result JSON).
Library integration: Use existing deterministic Python functions (e.g., quant_mcp.pricing, custom modules) without exposing each as an MCP tool; the agent imports them directly.
Multi-codebase support: Load libraries from external repos via codebases.yaml, with tracing of calls and per-task reproducibility (codebases.json).
Configurable agents: Choose Pi (DeepSeek) or smolagents; set timeouts, model, thinking mode, and max steps.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@quant-mcp-poc Price a European call with spot 100, strike 105, 6 months, 20% vol, 5% risk-free."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give Claude Desktop a task; let a coding agent write, run, and debug Python that uses your existing deterministic functions.
MCP is the entry point for the whole task. Your functions and classes stay in ordinary Python modules. Pi reads the repository source and examples itself, then writes and executes code that imports your library. There is no need to expose every function or method as an MCP tool or HTTP API.
This demo includes a small option-pricing library and three agent adapters: smolagents, Pi RPC, and a limited local demo that needs no model credentials. Pi with DeepSeek is the main repository-aware path; the smolagents setup is also documented below.
For the reviewed setup, external-library configuration, and a step-by-step demo sequence, see Office demo readiness.
Use Python 3.11+, uv, an installed Pi CLI (this integration was developed against Pi 0.83.0), and model credentials.
uv sync
cp .env.example .env
command -v pi
command -v uvIn .env, set:
QUANT_MCP_AGENT=pi
PI_EXECUTABLE=/absolute/path/to/pi
PI_PROVIDER=deepseek
PI_MODEL=v4flash
PI_THINKING=off
PI_API_KEY=your-api-key
QUANT_MCP_LIBRARY_MODULES=quant_mcp.pricingThe absolute Pi path is useful because Claude Desktop may have a different PATH from your terminal. Credentials are passed through the child environment, not command-line arguments. Leave PI_API_KEY blank to use the provider's configured authentication.
Add this to Claude Desktop's MCP configuration, replacing the paths:
{
"mcpServers": {
"quant-mcp-poc": {
"command": "/absolute/path/to/uv",
"args": ["run", "--project", "/absolute/path/to/quant-mcp-poc", "quant-mcp"]
}
}
}Reload MCP configuration, then ask Claude to use run_quant_coding_task to price a put with spot 100, strike 110, expiry in exactly 0.25 years, volatility 25%, rate 4%, and dividend yield 0%. Ask for premium and Greeks using the existing library.
Pi receives the repository path, task instructions, and registered module names. It does not receive a generated function catalog. It reads relevant source, docstrings, tests, and examples/ using its file tools. Its bundled extension provides one run_python execution tool, accepting either complete code or a script path in the task workspace.
Claude Desktop → MCP → Pi reads source/examples
→ writes code → run_python
→ validate + record library calls
→ traceback back to Pi for repair
→ return successful resultThe MCP adapter stops only after a successful validated execution, never merely because Pi wrote a file. There is no interactive review. The successful script is not replayed. Pi's source-editing tools are confined to the task workspace; the library is reference material. Arbitrary shell execution is not exposed in this task configuration; scripts execute through run_python.
Copy codebases.example.yaml to codebases.yaml, then edit the library list. codebases.yaml is ignored by Git because it can contain private local paths.
cp codebases.example.yaml codebases.yamlSet this in .env:
QUANT_MCP_CODEBASES_FILE=codebases.yamlEach entry has a Python module, its source repository, optional examples, optional extra python_paths, and a short description. Paths can be absolute or relative to the YAML file. The map replaces QUANT_MCP_REPO_ROOT and QUANT_MCP_LIBRARY_MODULES when enabled.
libraries:
- module: pricing_lib
source: /work/pricing-lib
examples: [/work/pricing-lib/examples]
description: Option pricing and Greeks.
- module: risk_engine
source: /work/risk-engine
examples: [/work/risk-engine/tutorials]
python_paths: [/work/shared-python]
description: Portfolio and scenario-risk classes.Pi receives the resolved map and reads only the relevant source and examples on demand. The execution environment adds each entry's python_paths, source/src when present, and source to Python's import path in YAML order. It traces calls to all listed modules, including public class methods. Each task saves its resolved map as codebases.json for reproducibility.
Write workflow demos in examples/ with clear inputs, units, return shapes, object construction, and method call order. See examples/reuse_pricing.py and examples/README.md. Pi reads relevant examples on demand. Public Python class methods are traced directly; there is no need to wrap each method as a function tool.
The executor records actual calls into registered library modules in library_calls.json. An import, constructor, or unexecuted call does not count. A task without an executed public library function or method is rejected and Pi receives the failure for repair. Recognizable handwritten option-pricing implementations are also rejected. The result schema and artifact paths are validated before success.
These are checks for accidental misuse, not a proof that every reported value came from the library. A script that calls a library and discards the result can still pass. The tracing currently covers Python functions/methods on the execution thread, not every native extension or worker thread. Generated Python is ordinary local code, not a security sandbox.
Each attempt runs in a fresh Python process. Persistent objects and database connection pools are not yet implemented. The MCP deadline bounds the whole task and terminates its process group. PI_EXECUTION_TIMEOUT_SECONDS defaults to 60 seconds per script; PI_MAX_EXECUTIONS defaults to 8 attempts. Model calls and repairs must all fit within the MCP task's timeout_seconds (default 300).
Pi's task configuration explicitly loads the bundled executor extension and disables automatic user extension/skill/context loading. Repository instructions and examples can be read explicitly. This avoids interactive or unrelated personal configuration in unattended MCP tasks.
Inspect agent_instruction.md, pi_rpc_events.jsonl, pi_rpc_stderr.log, analysis.py, run.log, library_calls.json, and attempts/ in the task directory. The MCP response also gives a worker log path.
For a direct CLI run with the same Pi adapter:
uv run quant-cli run --agent pi --timeout 300 --json \
"Read the source and price a put: spot 100, strike 110, T=0.25 years, vol 25%, rate 4%, dividend yield 0%."Related MCP server: OpenFinClaw CLI
Claude Desktop → MCP task tool → worker process → coding agent
↓
write complete analysis.py
↓
import your Python functions
↓
execute → validate → repair if needed
↓
result.json + saved artifactsEach smolagents code action is a complete script. The executor saves it as analysis.py, runs it with the project's Python interpreter, and checks the result schema and artifact paths. Failures and tracebacks go back to the agent for repair. A successful script ends the task and is not executed again by the runner.
MCP tasks run automatically, without terminal review or MCP elicitation. Generated code runs as ordinary local Python; the worker process is not a security sandbox. Result validation checks the output contract, not the numerical correctness of every calculation.
You need Python 3.11+, uv, and a DeepSeek API key.
From the project directory:
uv sync --extra smolagents-demo
cp .env.example .envEdit these values in .env (the example file initially selects Pi):
QUANT_MCP_AGENT=smolagents
DEEPSEEK_API_KEY=your-api-key
DEEPSEEK_MODEL=deepseek-v4-flash
DEEPSEEK_THINKING=disabledThe server loads the project's .env; existing process environment variables take priority. Keep credentials in .env, which is ignored by Git.
In Claude Desktop's MCP configuration, add the server to mcpServers. Replace both absolute paths below; command -v uv shows your uv path.
{
"mcpServers": {
"quant-mcp-poc": {
"command": "/absolute/path/to/uv",
"args": [
"run",
"--project", "/absolute/path/to/quant-mcp-poc",
"--extra", "smolagents-demo",
"quant-mcp"
]
}
}
}Use Developer → Reload MCP Configuration, or fully quit and reopen Claude Desktop, after changing the server configuration or .env.
Try asking Claude:
Use run_quant_coding_task to price a European put with spot 100, strike 110, time to expiry 0.25 years, annual volatility 25%, annual risk-free rate 4%, and dividend yield 0%. Use the registered functions and report the premium and Greeks, including their units.
The MCP tools are:
Tool | Purpose |
| Write, execute, and repair a task. |
| List recent tasks. |
| Read a saved text artifact or get a binary artifact's path. |
| Backward-compatible task entry point. Prefer |
For example, create src/quant_mcp/analytics.py:
def position_pnl(
entry_price: float,
current_price: float,
quantity: float,
multiplier: float = 1.0,
) -> float:
"""Return unrealized P&L in the same currency as the prices.
entry_price and current_price are prices per unit.
quantity is signed: positive for long positions, negative for short.
multiplier is units per contract; use 100 for a 100-share contract.
Fees and financing costs are excluded. Returns a single float.
"""
return (current_price - entry_price) * quantity * multiplierUse clear type hints and docstrings. Explain units, sign conventions, defaults, and the exact return shape. For dictionary results, document the keys. For rates and volatility, state whether inputs are decimals such as 0.25 or percentages such as 25. These details are passed to the agent and help it call your code correctly.
Add this line to .env:
QUANT_MCP_LIBRARY_MODULES=quant_mcp.pricing,quant_mcp.analyticsThis setting replaces the default module list, so include quant_mcp.pricing if you want to keep the pricing functions available. Reload the MCP configuration after changing it.
Discovery finds public Python functions defined in each registered module or its submodules. A registered package must expose those functions from its __init__.py. For example, a new function in pricing/primitives.py must also be imported in pricing/__init__.py to appear under the registered quant_mcp.pricing package. Private names beginning with _, classes, and functions imported from unrelated modules are excluded.
No tool decorator, MCP schema change, or agent adapter change is needed. The generated script can simply use:
from quant_mcp.analytics import position_pnl
pnl = position_pnl(entry_price=2.0, current_price=3.5, quantity=2, multiplier=100)
# 300.0From the project directory, inspect the same catalog the agent receives:
uv run --extra smolagents-demo python - <<'PY'
from quant_mcp.config import load_env_file
from quant_mcp.library_catalog import discover_library_catalog
load_env_file()
print(discover_library_catalog().render_for_prompt())
PYThen ask Claude to use run_quant_coding_task:
Calculate unrealized P&L for two long contracts bought at 2.00 and now worth 3.50, with 100 units per contract. Use quant_mcp.analytics.position_pnl and save the result.
Check the task's analysis.py to see the imports and calls. library_catalog.json and agent_instruction.md show exactly what was made available to the agent.
You can keep functions in a separate Python package. Install it into this project's environment, then register its module:
uv add --editable /absolute/path/to/my-quant-libraryQUANT_MCP_LIBRARY_MODULES=quant_mcp.pricing,my_quant_library.analyticsThe library needs to be importable by the server's Python interpreter. Register the module that defines the public functions, or a package that re-exports its own functions.
The bundled quant_mcp.pricing exports price_option and calc_greeks for date-based inputs, plus price_option_t and calc_greeks_t for time to expiry in years. Its docstrings specify decimal rates and volatility, per-unit prices, and Greek units.
The CLI calls the shared task runner directly. With QUANT_MCP_AGENT=smolagents in .env, this runs without review:
uv run --extra smolagents-demo quant-cli run --json \
"Price a European put: spot 100, strike 110, expiry in 0.25 years, vol 25%, rate 4%, dividend yield 0%."An explicit --agent smolagents enables interactive terminal review of generated scripts. This is separate from the automatic MCP path. The old review_mode tool argument is removed, and QUANT_MCP_REVIEW_MODE is ignored.
For a limited, credential-free option demo:
uv run quant-cli run --agent local \
"I am long an AAPL 180/200 call spread expiring Dec 2026. Spot 185, vol 24%, rate 4%."Inspect previous tasks:
uv run quant-cli list
uv run quant-cli read YOUR_TASK_ID result.jsonThe separate examples/smolagents_review_demo.py is an optional experiment using typed tool wrappers and interactive review. It is not the MCP adapter described above.
Setting | Default | Purpose |
|
| Choose |
|
| Comma-separated modules to discover. |
|
| Model used by the smolagents adapter. |
|
| OpenAI-compatible endpoint. |
|
| Set to |
|
| Timeout per model request, capped by the supplied task timeout. |
|
| Code-step budget, including repairs. |
The smolagents adapter reads DEEPSEEK_API_KEY, falling back to PI_API_KEY. MCP's timeout_seconds bounds the entire task, including model calls, execution, and repairs. A timeout terminates the worker and its child processes and returns a failed result.
Each task saves its work under artifacts/{task_id}/:
File | What to inspect |
| Original request and agent instructions. |
| Discovered function signatures and docstrings. |
| Generated code and execution output. |
| Structured status, summary, metrics, assumptions, and artifacts. |
| Agent steps and execution approval records. |
| Failed scripts and logs retained for debugging. |
Task-specific CSV, HTML, Excel, or other outputs are saved alongside these files when requested. Agent console output is isolated in artifacts/worker_logs/ so it cannot corrupt MCP's stdout protocol. MCP responses include the worker_log path.
If Claude appears stuck, inspect that worker log and the latest task folder. If a function is missing, check the catalog, module registration, and package exports. Reload MCP configuration after server updates so Claude uses the current process and tool schema.
uv sync --extra smolagents-demo
uv run --extra smolagents-demo pytestBackward-compatible option-analysis tool; prefer run_quant_coding_task for general use.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description reveals no side effects, prerequisites, return format, error behavior, or any other runtime characteristics. The only behavioral hint is 'backward-compatible', which is uninformative about actual behavior.
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 sentence, so it is concise, but it does not front-load the most useful information. The first clause 'Backward-compatible option-analysis tool' is vague and adds little, while the more actionable guidance about preferring run_quant_coding_task comes second. It is not verbose, but it is also not effectively structured to maximize agent utility.
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?
The tool is simple (two parameters, no output schema), but the description provides almost no context about what the tool does, how to use the prompt parameter, what timeout_seconds affects, or what the return value looks like. An agent would have to guess or inspect other tools to understand this one. This is far below the minimum viable completeness for a tool that is meant to be used.
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 0%, and the description does not mention either parameter (prompt or timeout_seconds). The schema itself provides only names and types, leaving the meaning and expected content of the prompt completely unexplained. The description fails to compensate for the lack of schema documentation.
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 identifies the tool as an 'option-analysis tool' but does not specify what analysis it performs, what inputs it expects, or what outputs it produces. The term 'backward-compatible' implies legacy status but adds no functional clarity. It is more specific than a tautology, but still too vague to distinguish from other analysis tools without opening the schema.
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 states to prefer run_quant_coding_task for general use, which is a clear directive for when this tool should be used (backward compatibility only) and when the sibling is the better choice. It names the alternative directly, giving the agent actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent generated quant analysis artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds the trait that artifacts are 'recent generated', implying recency ordering and that it only lists existing items rather than generating or modifying them. However, it does not explicitly state read-only status or whether it returns metadata versus artifact content; the output schema partially compensates for this.
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, front-loaded sentence with no filler. It immediately states the verb 'List' and the resource 'artifacts', and every word earns its place.
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?
With an empty input schema, no required parameters, and an output schema present, the description is sufficient to select and invoke this simple listing tool correctly. The only potential gap—distinguishing listing from reading a specific artifact—is partially clarified by the sibling tool names and the verb choice, but remains implicit.
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 is empty with zero parameters, so schema description coverage is 100%. The baseline for zero parameters is 4, and the description does not need to add parameter meaning. No additional parameter semantics are required.
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 the verb 'List' with the object 'recent generated quant analysis artifacts', clearly identifying both the action and the resource. It distinguishes from sibling tools such as read_artifact (which reads a specific artifact) and run_quant_coding_task (which performs a task) by focusing on enumeration of existing artifacts.
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 this tool should be used to retrieve a list of recently created quant artifacts, but it does not explicitly mention when to prefer this over read_artifact or exclude alternative tools. The usage context is implicit from the verb 'list', but no explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a text artifact, or return the path for binary artifacts such as xlsx.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| filename | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the key behavioral difference for binary artifacts (returns path instead of content), which is valuable. However, it omits other behaviors like error handling, authentication, or what happens when the artifact doesn't exist, so it's only partially 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?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the core action and the binary-artifact nuance. Every word earns its place.
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 output schema exists, return values need not be described. However, the tool has two required parameters with no schema descriptions and the description does not explain them. There is no guidance on how to obtain valid task_id or filename, nor any reference to sibling tools for context. The description is insufficient for an agent to call this tool correctly without external knowledge.
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 0%, so the description must explain the parameters. It does not mention task_id or filename at all, nor their meanings or relationships. The agent is left to infer that task_id identifies a task and filename an artifact, but this is not explicitly stated. The description fails to compensate for the lack of schema 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 states a clear verb (read) and resource (artifact), and further clarifies behavior for text vs binary artifacts (path return). It distinguishes itself from list_artifacts by focusing on reading a specific artifact rather than enumerating them.
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 when to use this tool (to read a specific artifact) without explicit exclusions or mention of alternatives. Since list_artifacts is a sibling, a note on using that for enumeration would help, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write, run, and debug a quant task automatically, without code-review prompts.
timeout_seconds bounds the whole task, including model calls and repairs.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals that the tool automatically writes, runs, and debugs, and that the timeout bounds the entire process including model calls and repairs. This adds meaningful context about iteration and resource limits, though it does not mention side effects like artifact creation or persistence.
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 sentences with no filler. The primary purpose is stated first, followed by the critical timeout constraint. Every sentence adds value and the description is appropriately front-loaded.
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 two parameters, no output schema, and no annotations, the description covers the core action and the timeout semantics. However, it does not mention what the tool returns, whether it creates artifacts, or any prerequisites for the task. For an automated coding task runner, this is a moderate gap but not critical.
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 0%, so the description must explain both parameters. It clarifies that timeout_seconds bounds the whole task, but it does not elaborate on the prompt parameter beyond the schema's field name. The prompt is central to the tool's operation, and its absence of any description leaves the agent without guidance on content or format.
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 states a clear verb-resource pair ('write, run, and debug a quant task') and is distinct from sibling tools like analyze_option_portfolio and read_artifact. It specifies the automated nature and excludes code-review prompts, so an agent can identify what this tool does.
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 usage for quant coding tasks and explicitly says 'without code-review prompts', but it does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives. No exclusions or alternative tool names are mentioned.
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.1.0analyze_option_portfoliolist_artifactsread_artifactrun_quant_coding_taskScored across 4 tools
Most tools are clearly distinct: run/analyze execute analysis, while list/read manage artifacts. The only real ambiguity is between run_quant_coding_task and analyze_option_portfolio, but the descriptions clarify that the latter is a backward-compatible specialized option-analysis tool.
All four tools follow a consistent verb_noun pattern: run_quant_coding_task, analyze_option_portfolio, list_artifacts, and read_artifact. There are no mixed conventions or inconsistent verb styles.
Four tools is a well-scoped surface for a POC: one general execution tool, one legacy/specialized analyzer, and two artifact-access tools. Each tool has a clear role with no unnecessary bulk.
The surface covers the core workflow of generating quant analysis and consuming the resulting artifacts. Minor gaps exist, such as no artifact deletion or task-status listing, but agents can generally work around these for a POC.
Trade across 22+ exchanges and brokers from any MCP-capable AI agent, no install required.
Coordinate coding agents through MCP using existing AI plans, saved work, and independent checks.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
