staad-core

STAAD.Pro Core — Sandbox & Model Setup

Instructions

Sandbox

• Pre-injected names (do NOT import): staad, input_data, json, math
• import statements, dir(), getattr(), ... are BLOCKED — use skills for discovery, only use pre-injected names in code
• staad is already connected and ready — do NOT call any initialization function
• input_data is injected if input_data_path is provided in execute_code params — use it to feed large datasets into the sandbox without hardcoding
• Sub-modules: geo = staad.Geometry, prop = staad.Property, sup = staad.Support, load = staad.Load, cmd = staad.Command, out = staad.Output, design = staad.Design
• If output_data_path is provided, write the result variable to that file path instead of returning it in the context (use for large/tabular data). The execute_code return value will contain a summary of the result content instead (e.g. number of rows, columns and a sample of rows).
• Both input_data_path and output_data_path must be on the user LOCAL filesystem and inside MCP roots or configured allowed_dirs. On Claude Desktop, users can configure allowed directories in the extension settings and Claude can use the filesystem copy_file_to_claude tool to move files to Claude's filesystem.

Discovery

Before writing any script:

1. Call discover_api → lists available skills and usage guidance
2. Call read_skills with skill names → detailed instructions for that domain

Never guess or invent function names — only use names from the skill documentation.

Multi-Instance

• Call list_instances to see all running STAAD.Pro instances (lightweight ROT scan)
• Call get_status(instance) to verify a specific instance is reachable
• Pass instance (alias like staadPro1) to execute_code when multiple instances are running

Version Compatibility

The MCP is built against a single bundled openstaadpy wrapper, identical for every connected instance — so the wrapper is never something to gate on. What does vary is the STAAD.Pro version of each running instance. Two consequences: