Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Session Transcript

session_transcript
Read-only

Export a session as a runnable Python script that regenerates the model, drawings, and simulations, with checks and provenance for every computed result.

Instructions

Export this session as a Python script that regenerates it (model, drawings, simulations) by calling these same tools in a fresh worker — and, with it, the record of what computed each number. Read-only: returns the script as text and writes nothing.

Covers one workspace (default: the current one). In the script, handles are variables, job polls are one s.wait(job), and inspection calls are dropped unless a later call used their result. Absolute paths become WORKDIR-relative. The header lists failed calls, run_script use and input files.

THE AUDIT SURFACE. Analysis calls are never dropped — every hand-calc, FEM read and *_submit is in the script, because they are the derivation, not inspection. Each analysis and solve result is checked whole: every number it reported becomes an s.check() and its verdict fields (fidelity, correlation, solver, gate pass) become s.expect(), so a replay that reached a different solver or fell back to a different correlation stops there instead of returning a plausible number. run_script code is carried verbatim with its SHA-256. With provenance (default), the script opens with a PROVENANCE record — AnkusDrive/FreeCAD/platform/substrate plus every solver the session reached, with its resolved path, substrate and probed version — and calls s.provenance(), which re-resolves that on the replaying machine and prints every difference. Hand this to anyone who has to answer "what exactly produced this figure?".

include_read_only: keep every inspection call. checkpoints: emit s.check()/s.expect(). prune_aborted: drop calls a transaction_abort undid. provenance=False skips the environment record (and the solver version probes it runs, ~0.1-3 s per solver).

Returns {workspace, script, calls, exported, skipped: {reason: count}, warnings, prerequisites, truncated, provenance}. Run it as python transcript.py [WORKDIR].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspaceNo
provenanceNo
checkpointsNo
prune_abortedNo
include_read_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.6

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond the annotations (readOnlyHint=true, openWorldHint=false) by detailing the exact behavior: read-only nature, workspace scope, conversion of handles to variables, job polls to s.wait(job), dropping of unused inspection calls, handling of absolute paths, and the inclusion of analysis calls with s.check() and s.expect() checks. It also mentions the performance cost of provenance probes. This is extensive and adds significant value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured, with a clear opening sentence stating the purpose, followed by a detailed breakdown of the script's behavior, the audit surface, and parameter options. It is front-loaded with the core action and then provides necessary details without redundancy. Every section earns its place, and the structure aids comprehension for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is exceptionally complete for a tool with five parameters and no output schema. It details what the script does, how to run it ('python transcript.py [WORKDIR]'), what the return object contains (workspace, script, calls, exported, skipped, warnings, prerequisites, truncated, provenance), and the audit surface. Nothing an agent needs to call it correctly or interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 0%, the description explains all five parameters in detail: workspace (default current one), provenance, checkpoints, prune_aborted, and include_read_only, including their effects. For instance, it states 'provenance=False skips the environment record (and the solver version probes it runs, ~0.1-3 s per solver).' This adds meaning beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: exporting the session as a Python script that regenerates it, including model, drawings, and simulations, plus the record of computations. It also distinguishes itself from potential siblings like journal_export by emphasizing the script's ability to regenerate the session and the audit surface. This is a specific verb-resource pairing, not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use the tool: for answering 'what exactly produced this figure?' and providing a reproducible script. It explains what the script includes and excludes, and describes options like include_read_only and provenance. While it doesn't explicitly name alternative tools, the usage context is unambiguous and practical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools