Skip to main content
Glama
chartergroup

topopt

by chartergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Show verify status

verify_status
Idempotent

Check the state of a topology optimization verification job and retrieve its result (verify.json) when done. Call again to monitor progress until the job reaches done, error, or failed.

Instructions

Show the state of a verify job and, when it is done, its result (the content of verify.json).

run_dir: the run folder (default: the folder of the last verify job of this server, else the last run). Call it again to watch the job. Nothing calls you back when the job ends: call it again in this turn until the state is done, error or failed, or end the turn and tell the user what to ask for the result. A promise of a later report cannot be kept. States: starting, meshing, solving, writing (the job works), done, error, failed (the process ended with no final status; log_tail has its last output) and none (no job and no result in the folder). It has elapsed_s and estimated_seconds_total (the estimate of verify_run). result: with a done job, add the result (set false to get the state only). result_matches_final_stl says whether the result is for the mesh file that the folder has now (result.run.verified_file: nominal.stl when the run has machining stock, else final.stl; part_only.stl after verify_run with part_only=true, and then the result has the block part_only). If it is false, the result belongs to an older file: run verify_run again. Tell the user the numbers; you decide what to do. plain (a done job with the result): one plain line for each load case (the value that is compared, who gave the allowable, the margin) and a line for what the check does not cover. They are a base for the answer to "will it break?". partial, coverage (a done job; also with result=false): partial is true when a check that the YAML or the call asks for failed or did not run; the other numbers still stand. coverage has ran (names), failed (name, reason) and not_run (name, reason, asked). A check that was not asked for is under not_run with asked false and does not make the result partial. Then summary and the first plain line say so.

Input Schema

NameRequiredDescriptionDefault
resultNo
run_dirNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.1/5.0
Behavior1/5

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

The annotations declare readOnlyHint=false, but the description frames the tool purely as a status/result viewer that shows state and returns verify.json content. That is an annotation contradiction: a read-only polling tool is described while annotations mark it not read-only. Although the description otherwise adds rich behavioral detail about states, coverage, and result matching, the contradiction forces a low score here.

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 purpose and then organizes polling, state values, result semantics, and coverage details. It is long and somewhat dense, but most sentences earn their place because the tool has no output schema and needs to explain complex status/result behavior.

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?

With no output schema, the description still fully explains the returned state values, result content, result_matches_final_stl, partial/coverage fields, plain output, and log_tail behavior. An agent has enough information to poll correctly and interpret the response.

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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: run_dir is explained as the run folder with its default, and result is explained as whether to include the result, including setting it false for state only.

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: show the state of a verify job and, when done, its result. It also distinguishes this from verify_run by explaining when a stale result means verify_run should be rerun.

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 explicitly says to call the tool again to watch the job, names the terminal states that end polling, warns that no callback will occur, and directs the agent to run verify_run again when result_matches_final_stl is false. That gives clear when-to-use and alternative guidance.

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