Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Setup Status

setup_status
Read-only

Diagnose an AnkusDrive installation by checking FreeCAD and solver components, reporting found/missing status with exact fix or install hints, and optionally verifying solver image authenticity.

Instructions

The machine-readable form of ankusdrive doctor — resolve FreeCAD and every solver family and report, per item, found/missing with the exact fix. Call this when the user asks to set up, diagnose, or finish installing AnkusDrive, then walk them through the per-item fix/install_hint commands for their platform.

Read-only and side-effect-free: nothing is executed or installed and no environment is mutated (verify_freecad_boot=True additionally boots FreeCAD once, time-boxed, purely to read back its version — leave it False unless the user doubts the install actually runs).

verify_image=True additionally checks, OVER THE NETWORK, that the solver container's image was signed by this repository — use it when the user asks whether the solvers they are running are authentic. It adds container_image.verification = {status, reason, repo, workflow, allowed_by_config, self_declared}, where status is: • verified — provenance names this repository's image workflow; • unsigned — no attestation: an image the user built themselves (common and legitimate), one published before signing existed, or no network/gh. Relay it as expected-for-a-custom-image, and mention ANKUSDRIVE_ALLOW_UNVERIFIED_IMAGE=1 silences it; • mismatch — an attestation exists but names a DIFFERENT repository. Say so plainly: that is an image claiming to be ours. No setting silences it; • unavailable — the check could not run (reason says why). Never report this as authentic. self_declared is what the image says about itself and is never evidence — only the signature is.

Returns {platform: {system, machine}, freecad: {available, path, source, version?, fix?}, install: {kind, source} (venv | pipx | uv_tool | uvx | mcpb — the install every fix string is written for), toolsets: {enabled, disabled: {family: {label, tools, enable}}} (tool families switched off in this install and exactly how to switch each on), run_script: {allowed, enable?} (whether the run_script tool may execute agent-written code here), solvers: {available, unwired, prepared_case_only, solvers: {name: {..., install_hint | wire_hint}}, families: {family: {solvers, available, unwired, prepared_case_only, any_available}}, extras}} — families[*].any_available is what gates each *_submit family, and every unavailable item carries its own fix string. A solver under prepared_case_only resolves but no AnkusDrive tool can build it a case, so it does not make its family available (SU2/cfd — issue #237).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
verify_imageNo
verify_freecad_bootNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.6
    • addedInput schema / properties / verify_image
      Added value: +{
+  "default": false,
+  "title": "Verify Image",
+  "type": "boolean"
+}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

The description explicitly states 'Read-only and side-effect-free: nothing is executed or installed and no environment is mutated,' which aligns with the readOnlyHint annotation. It goes beyond annotations by detailing the side effects of optional flags (verify_freecad_boot boots FreeCAD once time-boxed; verify_image performs a network check and adds a field). It also discloses the exact structure and semantics of the return object, including edge cases like 'prepared_case_only' and the meaning of verification statuses. No contradiction with 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?

Although the description is long and detailed, every sentence serves a necessary function given the tool's complexity. It opens with the core purpose, then explains optional flags and their behavioral implications, and finally delineates the return structure with clarifications. The content is front-loaded with the most critical information (purpose and when to use), and the structure is logical (flags explained before return values). No fluff or repetition.

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?

Given the tool's complexity (a diagnostic that returns a detailed nested object) and the absence of an output schema, the description is exceptionally complete. It documents every major part of the return value—platform, freecad, install, toolsets, run_script, solvers, families, extras—and clarifies nuanced behaviors like 'prepared_case_only' and the different verification statuses. The agent has all needed information to call the tool correctly and interpret results.

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

Parameters5/5

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

The input schema only provides types and defaults for the two boolean parameters, with 0% description coverage. The tool description fully compensates by explaining the purpose, effect, and appropriate usage of each parameter: verify_freecad_boot is described as optionally booting FreeCAD to read its version, and verify_image is detailed with its network check and the meaning of each resulting status (verified, unsigned, mismatch, unavailable). This adds significant semantic value beyond the bare schema.

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 states a precise purpose: 'The machine-readable form of `ankusdrive doctor` — resolve FreeCAD and every solver family and report, per item, found/missing with the exact fix.' It clearly identifies the resource (setup status) and the action (resolve and report), and distinguishes itself from siblings by being a read-only diagnostic tool. It also provides a usage trigger ('Call this when the user asks to set up, diagnose, or finish installing AnkusDrive'), making it unmistakable among the many sibling tools.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Call this when the user asks to set up, diagnose, or finish installing AnkusDrive' and even instructs follow-up behavior (walk them through fixes). It additionally explains when to set optional flags (e.g., 'leave it False unless the user doubts the install actually runs' for verify_freecad_boot, and use verify_image when checking authenticity). This level of context leaves no ambiguity about when to invoke this tool versus alternatives.

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