itasca-mcp

Overview Schema Source Related Servers Discussions Admin

itasca_browse_doc

Browse ITASCA documentation by path: list entries and read command, Python API, FISH, or reference pages for PFC, FLAC, 3DEC, MPoint, and MassFlow.

Instructions

Browse ITASCA documentation by path, like ls + cat over one documentation tree.

source picks the tree: commands (Itasca command syntax and keywords), python_api (the itasca Python SDK), fish (FISH intrinsic functions: name, signature, which versions have it), reference (contact/constitutive/joint model properties, range elements, plot items). Each level lists what is below it, so start at the top of a tree when unsure and descend.

Use itasca_query_doc when you only have keywords; its results are paths for this tool.

Input Schema

Name	Required	Description	Default
`path`	No	Path inside the selected tree; omit for the top level. - commands: the command as the engine spells it ('ball' lists ball commands, 'ball create' is the full doc, 'ball create radius' one keyword or section; a heading such as 'block contact' or 'structure beam' lists its commands, summary.groups names them) - python_api: dotted from itasca ('itasca.ball', 'itasca.ball.create', 'itasca.ball.Ball.pos') - fish: dotted intrinsic name ('ball' lists the namespace, 'ball.pos' shows its signature plus ball.pos.x/y/z) - reference: 'category item sub' ('contact-models linear', 'range-elements cylinder', 'plot-items zone contour', 'contact-models linearpbond pb_ten' one property or section) A page too large for one response leaves parts out (summary.omitted_sections / summary.compacted); summary.hint gives the path to read them.
`source`	Yes	Documentation tree: 'commands' (Itasca command syntax), 'python_api' (itasca Python SDK), 'fish' (FISH intrinsic functions), 'reference' (model properties, range elements, plot items).
`version`	No	Documentation version. Defaults to 9.0 (the current 9.x release); PFC also has 6.0 and 7.0, FLAC and 3DEC have 7.0; 9.0-only engines (MPoint, MassFlow) always resolve at 9.0. Gates commands, fish and reference entries by availability; python_api is a single 9.8 baseline whose docs carry their own availability notes.	9.0
`software`	Yes	ITASCA engine to query: 'pfc', 'flac', '3dec', 'mpoint', or 'massflow'. Required — there is no default engine.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.11.1Nov 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it explains that each level lists what is below, that large pages omit parts, and that summary.omitted_sections / summary.compacted and summary.hint tell the agent how to continue. It does not explicitly state read-only safety or permissions, but browsing semantics plus the truncation behavior disclosure are strong.

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

Conciseness4/5

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

The description is front-loaded with the core analogy and then structured by source tree, traversal, and alternative tool. It is efficient overall, though the source-tree list partially repeats the enum descriptions already present in the schema.

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 an output schema, the description does not need to explain return values, and it covers the important calling context: how to choose source trees, when to start at the top, version implications, and what to do when content is omitted. Nothing essential for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters in detail, including path examples and version availability. The description reinforces the role of source and traversal, but much of its path/version detail overlaps with structured schema descriptions, so this sits at the high-coverage baseline.

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 specific verb and resource: browsing ITASCA documentation by path, explicitly framed as 'ls + cat over one documentation tree.' It also distinguishes the four source trees and contrasts itself with itasca_query_doc, so an agent can identify the tool 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.

Usage Guidelines5/5

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

It gives explicit traversal guidance ('start at the top of a tree when unsure and descend') and names the alternative: use itasca_query_doc when you only have keywords, since its results are paths for this tool. That is clear when-to-use and alternative-routing guidance.

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

Deploy Server