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., "@aadc-mcp trace ~/pricers/european.py and show the branches closest to flipping"
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.
MatLogica's AADC engine and AADC Tracer, from your coding agent, on your own machine.
aadc-mcp is a local MCP server. It runs over stdio inside the Python
environment where the AADC packages are installed, and gives an agent in Claude Code, Cursor, Codex or any other MCP
client three things:
a measured environment check: which packages and versions are here, whether the engine runs (it records, replays and differentiates a two-line function and checks the answer), whether QuantLib tracing attributes anything, and the pip command for whatever is missing;
tracing of your own script with no code changes: the script runs with recording on and leaves a tape; a
QuantLib pricer written against aadc-quantlib-tracing needs nothing added;
the questions a tape answers: the constants the price depends on that nobody passed in, each at its C++ line; every decision frozen at record time and how far it was from going the other way; where a printed number was computed and the formula behind it; the source line with the recorded values written in, hash-checked against the compiled file; and a replay at new inputs that is exact when every recorded decision can be re-checked, and otherwise withheld, naming the decision it cannot vouch for.
Every number and every file:line in an answer is the engine's own output. The agent narrates; it never computes.
python3 -m venv aadc-env && . aadc-env/bin/activate
pip install "aadc-mcp[quantlib]" # Linux x86-64, macOS arm64: aadc + QuantLib 1.41 with source tracing
pip install aadc-mcp # elsewhere: aadc only (tracing of QuantLib needs Linux x86-64 or macOS arm64)
pip install "aadc-mcp[greeks]" # adds aadc-quantlib: QuantLib 1.38 with exact AAD sensitivities, every platformaadc-mcp --check prints what runs here, and the pip command for anything missing, before you register anything.
Register it with the absolute path of the console script, so the client always finds the right interpreter:
claude mcp add aadc -- /absolute/path/to/aadc-env/bin/aadc-mcp{ "mcpServers": { "aadc": { "command": "/absolute/path/to/aadc-env/bin/aadc-mcp" } } }Related MCP server: numproof
check_environment()
run_example("european_option") -> tape_id
inspect_tape(tape_id, "branches order=margin limit=5") -> the decisions closest to flipping, with file:lineThen on your own code: trace_script("/path/to/my_pricer.py"), inspect_tape(tape_id, "leaves kind=constant"),
inspect_tape(tape_id, "find value=<the printed price>"), replay(tape_id, "#<input>=<value>", "#<output>").
tool | what it does |
| packages, platform, licence state, engine self-test, tracing self-test, findings with fixes |
| run a |
| one question in the engine's grammar: |
| re-evaluate the tape at new inputs; exact when every recorded decision re-checks, withheld when one flips or cannot be checked |
| map the compiled source prefix to a local tree so |
| register a tape written elsewhere; list what the server holds |
| six bundled scripts: plain AADC (any platform) and unmodified QuantLib pricers |
Resources: two how-tos whose every snippet the tests run (using AADC: record once, replay, exact derivatives, batch,
QuantLib sensitivities; using the Tracer: the two ways to record, the switches, the questions in order, when a replay
is exact), the agent guide and the release notes shipped inside the aadc wheel, the verbs reference, a get-started
page, the package and platform matrix, and the tracing documentation (for agents, for people, model validation, how it
works). Prompts: get_started, validate_pricer, add_sensitivities.
The server runs your code on your machine; it is a developer tool, not a sandbox or a hosted service. A tape is one
execution at one input point: it supports "this executed" and "this constant is declared at file:line", never "this is
the only path". The source behind a line is shown when you point set_source_root at a matching QuantLib 1.41 ql/
tree; the answer says whether the file matches the compiled one.
Platforms follow the packages: aadc on Linux x86-64 and arm64, macOS arm64 and Windows x86-64 (CPython 3.10 to 3.14);
aadc-quantlib-tracing on Linux x86-64 and macOS arm64. Intel Macs are not supported: the engine has no wheel for them.
Proprietary, MatLogica. The aadc engine installs in Community Edition: non-commercial and academic use. Commercial
use needs a licence: info@matlogica.com.
What this interpreter can do with AADC and the Tracer, measured: installed packages and versions, platform, licence state, an engine self-test (record, replay, reverse: dz/dx = 6 at x = 3), a tracing self-test (one traced QuantLib call must attribute leaves to QuantLib's C++), and findings with the pip command that fixes each. Call it first; call it again after installing anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden, and it does disclose a lot: which checks run, that an engine self-test actually executes record/replay/reverse, that a traced QuantLib call must attribute leaves to C++, and that findings include the pip command that fixes each issue. It does not state whether the tool itself installs anything or how long the self-tests take, so an agent can't fully predict cost or side effects.
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 action guidance ('Call it first; call it again after installing anything') is front-loaded before the long enumeration of checks, and every listed check is specific rather than filler. The middle sentence is dense and comma-heavy, which costs a little readability.
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 no annotations and no output schema, the description must convey what comes back, and it does: package versions, platform, licence state, two self-test outcomes, and actionable findings. What's missing is the shape/format of those findings and whether remediation is advisory or applied, but for a zero-parameter diagnostic the coverage is close to 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?
The schema has zero parameters, which is the baseline-4 case; the description correctly implies no inputs are required and focuses entirely on what the call reports. Nothing about parameters needs explaining.
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?
States a specific verb-and-resource: it measures what the interpreter can do with AADC and the Tracer, enumerating concrete checks (package versions, platform, licence, engine self-test, tracing self-test, findings with fix commands). The expected self-test result (dz/dx = 6 at x = 3) grounds the purpose in observable output rather than restating the tool name.
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?
'Call it first; call it again after installing anything' gives explicit ordering guidance and a re-invocation trigger, which routes the agent correctly against the trace/replay siblings. It doesn't name an alternative tool or state a when-not condition, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The source of one bundled example, to read, copy or adapt.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It implies a read-only retrieval of bundled source, but it does not clarify permissions, error behavior for an unknown name, or what exactly is returned.
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 wasted wording and front-loads the resource. It is appropriately brief, though brevity contributes to under-specification elsewhere.
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?
For a one-parameter retrieval tool with no output schema, the description should clarify return content and name discovery. It mentions 'source' but does not explain whether that is code, a file path, or text, nor how to find valid example names.
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 single required 'name' parameter is undocumented in both schema and description. The description does not explain that 'name' identifies a bundled example or how to discover valid names.
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 resource as the source of one bundled example and gives intended uses (read, copy, adapt), but it does not use a clear retrieval verb and does not explicitly distinguish itself from siblings like run_example or list_examples.
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 phrase 'to read, copy or adapt' implies when the tool is useful, but there is no explicit guidance on when to choose it over run_example, list_examples, or other siblings, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the tape one question in the engine's own grammar and get its text answer plus the parsed header. Verbs: 'stats' | 'leaves [kind=input|constant] [by=leaf] [limit=N]' | 'branches order=margin [limit=N]' | 'sites [file=NAME] [limit=N]' | 'at FILE:LINE [context=N]' (source with the recorded values; hash=ok means the file shown is the one compiled) | 'find value=X' (where a printed number was computed) | 'origin #N' (the formula behind a value) | 'uses #N' | 'cone #N' (which leaves can move a value, by derivative or only by a branch) | 'source root=COMPILED=LOCAL' (map compiled paths to a local source tree) | 'replay ...' (prefer the replay tool). Ids are #N from earlier answers. A malformed request answers status=error in the header, never an exception.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| tape_id | Yes | ||
| max_lines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavior: malformed requests return status=error in the header rather than raising, and hash=ok certifies that the displayed source is the compiled one. It never states that this is a non-mutating query, nor does it describe the header's other fields, output size limits, or cost, leaving meaningful behavioral ground uncovered.
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?
Purpose is front-loaded in the first sentence, followed by a compact verb table where each entry pairs a verb with its qualifiers and a parenthetical hint. The density is high and almost every clause earns its place; the parenthetical glosses on 'cone' and 'source' are the only places that could be trimmed.
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?
For a tool with no annotations and no output schema, the description explains the return shape only loosely (text answer plus header, with status and hash singled out). It omits how to obtain a valid tape_id and what max_lines bounds, both of which an agent needs before its first successful call.
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 compensate, and it does so thoroughly for `request` by spelling out the grammar and the limit=N modifier. However, `tape_id` is never mentioned (the agent must infer it comes from earlier load_tape/list_tapes results) and `max_lines` (default 40) is entirely unexplained, leaving two of three parameters undocumented in both schema and prose.
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 first sentence names a specific action (ask the tape one question) and states exactly what comes back: the text answer plus the parsed header. The enumerated verb list makes the resource concrete and separable from siblings like trace_script or replay. It stops short of 5 only because 'tape' and the surrounding domain vocabulary are never grounded for a newcomer.
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?
One explicit routing rule is given: "replay ... (prefer the replay tool)", which correctly steers the agent away from this tool for that verb. For the rest there is no guidance on when to reach for inspect_tape versus load_tape, trace_script, or list_tapes, so the choice is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bundled scripts to start from: plain AADC (any platform), and unmodified QuantLib pricers that aadc-quantlib-tracing records (Linux x86-64, macOS arm64). mode=auto scripts are traced as they are; mode=explicit scripts record themselves and print sensitivities. Each is a starting point to copy and edit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavioral context: platform support (Linux x86-64, macOS arm64) and the difference between mode=auto (traced as-is) and mode=explicit (self-recording, prints sensitivities) scripts. What is missing is any statement of the return shape, which matters since there is no output schema.
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?
Three sentences, but the first is a fragment ('Bundled scripts to start from: ...') and the middle sentence packs platform and mode details that are more about the examples than about the listing action. The key fact, that this enumerates examples, is never 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?
For a simple no-arg listing tool with no output schema, the description should at minimum say what each list entry contains (name, path, platform, mode) so the agent knows what it can pass onward. It gives context about the scripts' contents but leaves the returned structure entirely unspecified.
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 tool takes zero parameters, so the baseline is 4. The description correctly introduces no parameter discussion and spends its words on the objects being listed, which is the right allocation for a no-arg tool.
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 describes what the bundled scripts are (plain AADC vs unmodified QuantLib pricers) but never states the actual operation: that it returns a list of available examples. An agent must infer from the name that this is an enumeration tool, and the two example families are only loosely framed as list contents.
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?
'Each is a starting point to copy and edit' implies the reason to call it (find a template), but there is no explicit when-to-use versus get_example, run_example, or trace_script, all of which operate on the same objects. The mode=auto / mode=explicit note hints at follow-up usage without naming the follow-up tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tapes this server holds: id, file, size, the script that produced each, and the source roots applied.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It does describe the returned fields (id, file, size, script, source roots), which adds useful context about output. However, it does not state that the operation is read-only, whether it has side effects, or any access requirements, leaving a gap.
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 and front-loads the resource and fields, with no extraneous text. It could be slightly more structured by starting with a verb, but it remains 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 low complexity (no parameters, no annotations, no output schema), the description covers the essential return fields but omits usage context and behavioral traits. It is adequate but not fully 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?
With zero parameters, the schema is empty and the description need not explain parameters. The baseline score of 4 applies.
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 a specific resource (tapes held by the server) and enumerates the metadata returned, making it clear this is a listing tool. However, it does not explicitly state a verb like 'list' or differentiate from siblings such as inspect_tape, so it does not reach the highest clarity.
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 guidance is given about when to use this tool versus alternatives such as inspect_tape or load_tape. The description is purely declarative and lacks any when/when-not or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register an existing .tape file written earlier (by trace_script, by a script's own save_tape(), or downloaded from a report) and return its tape_id and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It helpfully discloses the return payload ('tape_id and stats'), which is valuable given there is no output schema, but it does not state whether registration is idempotent, what happens with a nonexistent or malformed path, or whether it has side effects on persistent state.
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?
One sentence, front-loaded with the action, parenthetical provenance kept compact, and the return value stated at the end. No filler.
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?
For a one-parameter tool this covers the essentials of what it does and what it returns, but it leaves path resolution and failure behavior unstated, both of which matter for a registration operation that presumably persists state.
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% for the single 'path' parameter, so the description must compensate. It only implies the parameter is a path to an existing .tape file; it does not say whether it is absolute or relative, whether it resolves against a source root (a sibling tool named set_source_root exists), or what file extensions are accepted.
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?
Uses a specific verb ('register') on a specific resource (an existing .tape file) and enumerates the provenance of tapes it accepts, which implicitly distinguishes it from trace_script, which produces tapes. It never explicitly contrasts with siblings, but the read/register-vs-create distinction is inferable from the text.
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 phrase 'written earlier' implies the caller should already have a tape on disk, which is a usable usage signal. However, it never says what to do instead when a tape has not been produced yet (trace_script) or when the caller wants to view an already-registered tape (inspect_tape, list_tapes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-evaluate the tape at new inputs without re-running the model. assignments: '#12=101' or '#12=101,#15=0.21' (leaf ids from 'leaves kind=input' or 'leaves by=leaf'); out: the output id from 'find value='. survives=true: the recorded path holds and value is exact (equal to a fresh run to the last digit). survives=false: WITHHELD; flipped names the decision (file:line, decided true -> false) and unchecked the conversions the tape cannot check. There is no value to quote in that case. A tape read back from a file keeps no operand for a counted conversion, so on most QuantLib tapes a replay is withheld with unchecked naming the line (often errorfunction.cpp:200); say so and re-run the script at the new inputs for the price. path_recorded=true returns the recorded path's value labelled as such, for comparison only.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| tape_id | Yes | ||
| assignments | Yes | ||
| path_recorded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it defines survives=true/false outcomes, states that a withheld replay has no value to quote, explains that flipped/unchecked name the decision and the unchecked conversions, and warns that file-read tapes lose operands for counted conversions so most QuantLib replays are withheld. That is substantial non-obvious behavioral context; only error/permission behavior and side effects are absent.
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 the purpose, and each sentence carries information, but the body is a dense semicolon-and-quote chain referencing other tools' output formats that is hard to parse on a first read. It could be restructured into short labelled lines (survives=true / survives=false / path_recorded) without losing content.
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?
For a 4-parameter tool with no output schema and no annotations, the description covers the outcome space (survives true/false, flipped, unchecked, path_recorded) and the meaning of the important inputs. Minor gaps: tape_id semantics and error behavior for malformed assignments are unaddressed.
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 compensate and largely does: it gives a concrete assignments syntax with example ('#12=101,#15=0.21'), explains where leaf ids and the 'out' id come from, and defines path_recorded as returning the recorded path's value 'for comparison only'. Only tape_id is left undefined, and it is largely self-evident.
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?
Opens with a specific verb+resource: 'Re-evaluate the tape at new inputs without re-running the model', which distinguishes it from load_tape/inspect_tape by naming the key differentiator (no model re-run). It is jargon-dense but an agent can tell what the tool does and roughly how it differs from the tape-inspection siblings.
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?
Gives an explicit fallback ('say so and re-run the script at the new inputs for the price') when survives=false, which is real routing guidance. However it never states when to prefer replay over inspect_tape or trace_script, and no prerequisites (e.g., the tape must match the script that produced the inputs) are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy one bundled example into the server's working folder, run it with tracing on and return its tape_id, its printed output and the tape's stats. Then question the tape with inspect_tape and replay.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses side effects (copying into the server's working folder, running with tracing on) and return content, but it omits important behavior for an execution tool: what happens on timeout, whether an existing working folder is overwritten, error behavior for missing examples, and any permission or sandbox constraints.
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, front-loaded with the primary action, and every clause contributes useful information. No filler or repetition.
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 description covers the main action, side effects, and return values (useful since no output schema exists), but it is incomplete for an execution tool: timeout behavior and error conditions are unaddressed, and the 0% parameter coverage leaves important invocation details undocumented. Adequate but with clear gaps.
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 compensate. It only weakly implies the `name` parameter via 'one bundled example' and says nothing about `timeout_s`, leaving a required parameter and a meaningful execution-control parameter unexplained. This is a significant gap for a two-parameter tool with no 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?
States specific verbs and resources: copies one bundled example, runs it with tracing, and returns tape_id, printed output, and tape stats. It names the follow-up tools (inspect_tape, replay), so an agent can distinguish it from siblings like get_example or list_examples without opening either 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?
It implies the workflow by saying to then question the tape with inspect_tape and replay, which is useful downstream sequencing. However, it does not say when to choose run_example over list_examples or get_example, nor does it mention prerequisites such as requiring a valid example name or that the example must already be listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map the compiled source prefix recorded on the tape (for aadc-quantlib-tracing 1.41 it is /project/work/QLAADC/ql) to a local directory holding that source, so 'at FILE:LINE' and 'origin' can show the code. Later answers say hash=ok when the local file is the one the library was compiled from and hash=MISMATCH when it is not; a mismatch is reported, never silent. Remembered for this tape.
| Name | Required | Description | Default |
|---|---|---|---|
| tape_id | Yes | ||
| local_dir | Yes | ||
| compiled_prefix | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it discloses persistence ('remembered for this tape') and the verification outcome (hash=ok vs hash=MISMATCH, mismatch reported not silent). It omits whether re-calling overwrites an existing mapping, whether a bad prefix is rejected, and what an invalid local_dir does.
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?
Three sentences, front-loaded with the core mapping action, and the version-specific example earns its space by making compiled_prefix concrete. Slightly dense but no filler.
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?
No output schema and no annotations, yet the description explains the effect, the persistence scope, and the verification semantics that a caller needs. The remaining gap is operational: no error behavior and no guidance on obtaining the tape_id.
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 carry all three parameters. It does reasonably: compiled_prefix gets a concrete example value and local_dir is defined relationally, but tape_id is only alluded to via 'this tape' with no hint where the id comes from (e.g., list_tapes), and no format expectations are given for any field.
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?
Specific verb ('map') and specific resources (compiled source prefix on the tape -> local directory), plus the downstream effect on 'at FILE:LINE' and 'origin' output. It is implicitly distinguishable from siblings like load_tape or inspect_tape, but never names or contrasts them explicitly.
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 motivation is clear (so source locations can be shown), which implies the situation to use it, but there is no explicit trigger ('call after load_tape', 'when paths are unresolved') and no stated alternative or when-not-to-use guidance among the nine sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Python script with tracing on and keep the record (tape) it leaves. The script needs no changes: it runs in its own directory with AADC_TRACE=1, so every calculation through aadc types or an AADC-built library such as aadc-quantlib-tracing is recorded with its source coordinates. Returns tape_id, the script's stdout and stderr, the engine's census (frozen branch sites, outputs) and stats. A script that records itself and ends with f.save_tape() writes to AADC_TRACE_OUT; mark its first line with 'mode=explicit'. outputs: optional AADC_TRACE_OUTPUTS entries, e.g. ['value=123.45'] or ['pricer.py:42'], to name the program's results on the tape. python: another interpreter to run under (the one where the user's packages live). This runs the user's own code on the user's own machine; it is not a sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| path | Yes | ||
| python | No | ||
| outputs | No | ||
| workdir | No | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden and does so well: it discloses the tracing environment variable, that the script runs in its own directory, the outputs (tape_id, stdout, stderr, census, stats), and the important caveat that this is not a sandbox and executes the user's own code. It omits details on filesystem side effects beyond AADC_TRACE_OUT and on failure/timeout 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?
Front-loaded with the core action and result, then layered detail. Dense but mostly purposeful; the run-on clause about AADC_TRACE could be trimmed. Nothing is repeated from the schema verbatim.
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 no output schema and no annotations, the description supplies the return shape and the safety caveat that an agent needs. Remaining gaps are the undocumented 'args' and 'timeout_s' parameters and what happens on timeout or script failure.
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 compensate. It meaningfully explains 'outputs', 'python', and the explicit-mode convention, and implies 'workdir' via 'runs in its own directory', but 'args', 'path', and 'timeout_s' are left entirely to field names. Partial compensation for a six-parameter tool.
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?
States a specific verb and resource: run a Python script with tracing enabled and retain the resulting tape. It is concrete about the mechanism (AADC_TRACE=1, recording through aadc types) and distinguishes itself functionally from tape-reading siblings by producing a tape_id. It does not explicitly name a sibling (e.g. run_example) to contrast against, keeping it at 4.
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?
Gives clear conditional guidance: the script needs no changes, and a self-recording script ending in f.save_tape() must be marked 'mode=explicit' on its first line. It also tells the agent that 'python' is for running under the interpreter where the user's packages live. No explicit when-not or sibling-alternative routing is provided.
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.2check_environmentget_exampleinspect_tapelist_exampleslist_tapesload_tapereplayrun_exampleset_source_roottrace_scriptScored across 10 tools
Most tools have clearly distinct purposes across the tracing lifecycle: environment check, trace/run, load/list, inspect, replay, source mapping, and examples. Minor overlap exists because inspect_tape supports a 'replay' verb despite a dedicated replay tool, and run_example and trace_script both run code and produce tapes, though their scopes are clearly differentiated.
Names are consistently snake_case and mostly follow a verb_noun pattern such as check_environment, trace_script, inspect_tape, load_tape, and set_source_root. The only notable deviation is the bare verb 'replay', which is still clear but breaks the otherwise predictable pattern.
Ten tools is well-scoped for a tracing, inspection, and replay server. Each tool corresponds to a meaningful stage or object in the workflow, with no obviously redundant or trivial tools.
The surface covers the core lifecycle: environment validation, tracing scripts and examples, loading and listing tapes, inspecting and replaying tapes, source-root mapping, and example discovery. Minor gaps remain around tape cleanup/removal or export, but agents can work around them for the stated tracing and debugging purpose.
Trading MCP server for AI agents, with live market data, account reads and controlled execution.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Production MCP server for US equity and options intelligence: real-time IV radar, Monte Carlo simulation, options pressure, strategy backtesting, AI prediction, pre-trade risk analysis, and automated stock research reports.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
