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

Annotations already declare destructiveHint=true and idempotentHint=false, yet the description adds substantial context: dependency ordering of steps, full-batch validation in preview, stop-at-first-failure, no rollback ("what was already applied stays"), and that analysis results are discarded. The notable omission is how preview versus apply is actually signalled — the two-step protocol is never tied to the confirm_token parameter that implements it.

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

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

Purpose and the two-step model are front-loaded, followed by ordering, validation, limits, and failure semantics in a logical sequence. Dense but every sentence carries operational information; no filler.

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

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

For a destructive batch mutation with no output schema, the description covers ordering, limits, failure behavior, and even the shape of the result (steps done, failed step, steps not run). The remaining gaps — meaning of `product` and the confirm_token preview/apply mechanism — are real but narrow.

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

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

Schema description coverage is reported as 0%, so the description must compensate; it does explain the Operation shape (table, action, records as {id: fields}, or ids) and anchors it to write_records/delete_records. However, it says nothing about the top-level `product` enum (gen/civil) or `confirm_token`, leaving two of three parameters semantically unexplained.

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

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

States a specific verb set (create/update/delete) against a specific resource (records in several tables at once), with concrete examples (materials, sections, nodes, elements, load cases, loads). It is clearly distinguishable from the per-call siblings write_records and delete_records, which it names as the single-step equivalents.

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

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

Establishes the workflow explicitly ("Two steps: preview, then apply"), states the batch limits (20 operations, 200 records) and one exclusion ("A UNIT change is not taken here"). It does not explicitly say when to prefer write_records/delete_records over this tool, so the choice between batch and single-call paths is left to inference.

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

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

Beyond the annotations, it discloses that the capture reflects whatever viewpoint, active elements and result display the user has set and does not modify them, plus a hard 2000-pixel cap per dimension and the default-to-window-size behavior. The only tension is that readOnlyHint=false while the description stresses non-mutation, which is explainable by the POST endpoint but is not addressed.

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

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

Three tight sentences with no filler, and the core behavior is front-loaded ahead of the sizing details. The mid-sentence line break between the first summary line and 'Shows the current view' slightly disrupts reading flow but costs no content.

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

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

It correctly indicates the return is a PNG, which matters since there is no output schema. It is still incomplete for a tool with a required enum parameter: nothing explains what `product` selects or how it affects the captured view.

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

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

With 0% schema description coverage the description must carry the load: it gives units, the 2000-pixel maximum and the omit-for-default behavior for width and height. However, the required `product` parameter and its gen/civil enum are never mentioned, leaving a substantive gap.

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

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

States a specific verb and resource: produces a PNG image of the model window as NX currently displays it, with the underlying endpoint noted. No sibling tool does screen capture, so it is unambiguously distinguishable from read_model_info, show_result, and the other inspection tools.

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

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

The description makes clear this is a snapshot of the user's current view, not a configurable render, and tells the caller to omit width/height to get the window size. It does not name an alternative or a when-not-to-use condition, but no sibling competes for this purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the return payload (status plus program name) and the important caveat that a blocked session can report connected and fail on later reads. It does not mention auth requirements or timeouts on this call itself, which keeps it short of a 5.

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

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

Three short sentences with zero filler: purpose first, return values second, and the non-obvious caveat last. Every sentence contributes information the agent cannot get from the schema or annotations.

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

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

With no output schema, the description correctly fills the gap by naming what is returned (connection status and program name). The blocked-session caveat covers the main failure mode. It stops short of saying what to do when the check fails or how long a check may take, which would complete the picture for a connectivity probe.

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

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

Schema description coverage is 0%, so the description carries the burden for the single `product` parameter, and it only refers to it as 'the given MIDAS NX product'. The enum (gen, civil) constrains the choice mechanically, so an agent can still populate it, but the description adds no explanation of what each product value selects.

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

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

States a specific verb and resource: check whether a given MIDAS NX product is reachable through the Open API. It also says it returns connection status and program name, so the agent knows exactly what the call produces. It doesn't explicitly contrast itself with the read/analysis siblings (read_table, run_analysis, etc.), but the connectivity-check framing makes its distinct role evident.

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

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

Usage is implied rather than stated: this is a pre-flight connectivity probe, and the note that a blocked NX session can still report 'connected' hints at how to interpret and when to distrust a positive result. There is no explicit 'call this before X' or 'do not use this to verify data access' guidance, and no alternatives are named.

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

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

Annotations already declare destructiveHint=true, but the description adds substantial context they cannot: the cascading deletes NX performs (load case loads, combination entries, nodal loads, supports, masses, beam loads, end releases, pressure loads), the 50-id cap, and post-conditions where /DESIGN tables may reset to defaults or remain unchanged. This is exactly the disclosure an agent needs before a destructive call.

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

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

Purpose and the two-step protocol are front-loaded, then constraints, then side effects, then result semantics. Dense but every sentence carries operational information; the parenthetical explanations of why records are refused earn their space.

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

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

With no output schema, the description usefully explains what the result reports (which records were reset, unchanged, or removed from other tables). The main omission is how to obtain and pass confirm_token, which is central to a two-step destructive flow.

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

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; it does well for ids (listed ids only, one DELETE per id, max 50) and table (a single /db or /DESIGN table). It says nothing about confirm_token, whose presence drives the preview/apply protocol, and nothing about product (gen vs civil).

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

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

Opens with a specific verb and resource plus hard scope: 'Delete records by id from one /db or /DESIGN table,' and immediately bounds it ('one DELETE per id; there is no way to empty a table here'). It does not name a sibling such as write_records to contrast with, so differentiation is left implicit, but the operation is unmistakable.

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

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

'Two steps: preview, then apply' gives a clear call sequence, and the refusal rules (nodes used by elements, used materials/sections/thicknesses) tell the agent what preconditions must hold. The gap is that the preview and apply steps are never tied to the confirm_token parameter, and no alternative tool is named for cases where deletion is refused.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and repeatability are covered. The description adds that this is a metadata GET against /info/db/<TABLE> and how it fits into a read workflow, but says nothing about what the response contains (field names, types, descriptions) or limits.

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

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

Two short sentences, front-loaded with what the tool returns and followed by the actionable sequencing instruction. No filler and nothing that could be cut.

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

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

There is no output schema, so the description is the only source for what a 'field schema' looks like, and it does not describe the returned shape at all. Combined with the unexplained 'product' parameter, an agent knows when to call it but not exactly what it will get back.

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

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 largely does not. 'One /db table' loosely implies the table parameter, but the required 'product' param with its gen/civil enum is never mentioned, leaving the agent to guess why a product scope is needed for a schema lookup.

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

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

The description states a specific verb and resource: returns the NX server's own field schema for a single /db table, and it even pins the underlying endpoint (GET /info/db/<TABLE>). That distinguishes it from read_table (data) and list_tables (enumeration), though it never explicitly contrasts itself with the sibling list.

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

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

It gives explicit sequencing guidance: 'Call this before read_table to learn what each field means,' naming the alternative tool and the condition that selects it. It does not say when not to call it or whether it is ever needed standalone, but the trigger condition is clear.

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

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

Annotations declare destructiveHint=true and idempotentHint=false; the description adds substance beyond that — that existing combinations are preserved, new ones are appended as cLCB1, cLCB2, and that existing analysis results are discarded. The unexplained gap is the preview/apply handshake, which is the mechanism behind the destructive gating.

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

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

Front-loaded with the purpose, then the kind breakdown, then behavioral notes — a sensible order with little waste. The mid-sentence line breaks are awkward but don't obscure meaning.

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

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

For a destructive mutation with no output schema, the description covers what changes, what persists, and roughly what is returned. Missing is any description of the preview step and confirm_token semantics, which an agent needs to invoke this tool safely and correctly.

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

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

Schema coverage is 0%, so the description must carry the load. It does well for 'kind', mapping each enum value to a code standard and target table, and implicitly covers 'product' via the Gen-only note. 'confirm_token' is never mentioned at all, leaving a required-for-safety parameter undocumented.

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

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

Opens with a specific verb and resource — 'Have NX add its KDS design load combinations' — and explains where they land (LCOM-CONC/LCOM-STEEL/LCOM-SRC). It also scopes the tool to Gen NX, which separates it from anything a Civil-only workflow would call.

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

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

States the two-step preview-then-apply workflow and an explicit exclusion ('Gen NX only: Civil NX has no such command'), which is a real when-not rule. It stops short of naming which sibling tool performs the preview step or how the confirm_token gates the second step.

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

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

Annotations already cover read-only, idempotent, and closed-world, so the safety profile is handled. The description adds genuinely new behavioral context: no NX call is made (no live model round-trip) and each category states what NX must have done before its tables produce data — a prerequisite signal an agent would otherwise have to discover by trial.

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

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

Front-loaded purpose sentence followed by a compact category block and a search note — no filler. The sentence 'Each category says what NX needs before its tables have data' is slightly oblique about what the agent will actually see, but the density is justified given four enum values to explain.

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

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

With no output schema and an undocumented input schema, the description supplies the missing shape: a categorized list of table types, filterable by text and category, requiring no NX call. It does not spell out filtering precedence when both search and category are supplied, a minor gap for a two-parameter discovery tool.

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

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 the burden. It does: 'search' is defined as case-insensitive text matched against both the type and its name, with concrete examples ('reaction', 'beam', 'drift'), and each 'category' enum value is explained in terms of the table families it contains.

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

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

Opens with a specific verb+resource: listing the result/report table types that the sibling tool result_table accepts, grouped by category. The four named categories (model, analysis, story, design) with concrete example tables make it immediately distinguishable from siblings like list_tables or describe_table.

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

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

Strong implied usage: this is the discovery step that tells you which values result_table will accept, and it explicitly states 'No NX call is made', so an agent knows it is cheap and safe to call first. It does not explicitly compare itself to the sibling list_tables or say when that alternative is preferable, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds meaningful context beyond that: 'No NX call is made', telling the agent the call is a purely local metadata lookup that does not touch the model. It stops short of describing result ordering or truncation behavior, though an output schema exists.

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

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

Purpose is front-loaded in the first sentence and each subsequent clause maps to a parameter, with no filler. The line-broken, fragment-style formatting is slightly harder to parse than flowing prose, but nothing is redundant.

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

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

Both parameters are described, an output schema covers the return shape, and annotations cover safety and idempotency, so nothing essential to calling this two-parameter read tool is missing. The only optional addition would be an explicit pointer to describe_table/read_table as the follow-up step.

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

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 largely does: 'search' is specified as case-insensitive text matched against both table name and title, with example queries ('load', 'section', 'design'). 'product' is explained only loosely as 'keep only tables that product supports', leaving the mapping of the gen/civil enum values to table families unstated.

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

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

States a specific verb and resource ('List the tables this server can read') and immediately distinguishes the two catalog families it covers: '/db model data' (e.g. NODE) and '/DESIGN design parameters' (e.g. DESIGN/STEEL/DSTL). An agent can tell this apart from siblings like list_result_tables or read_table without opening any schema.

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

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

Usage context is only implied: the reader infers this is a discovery/enumeration step that precedes describe_table or read_table, but no explicit when-to-use or when-not-to-use statement is given. There is no exclusion relative to the closely named sibling list_result_tables, which an agent could plausibly confuse with this tool.

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

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

Annotations already cover read-only, idempotent, closed-world behavior, and the description adds a genuinely non-obvious trait: partial failure is tolerated, with per-table errors reported while remaining counts still return. It does not address what happens if the model itself cannot be read or whether counts are cached/live.

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

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

Two short sentences, front-loaded with the returned content, with no filler. The mid-sentence line break is a minor formatting wart but nothing is wasted.

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

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

With no output schema, the description does the right thing by enumerating returned fields and the partial-error shape. However, for a tool with a required enum argument, leaving that argument entirely unexplained is a meaningful completeness gap.

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

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

Schema description coverage is 0% and the single required parameter 'product' (enum gen/civil) carries no explanation in the schema. The description never mentions 'product' at all, so it does not compensate for the gap — an agent must guess that it selects which product's model to summarize.

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

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

The description states a concrete resource and scope: record counts for specific tables (nodes, elements, materials, sections, thicknesses, static load cases) plus the unit system. That is far more specific than the name alone. It does not explicitly contrast itself with siblings such as read_model_info, list_tables, or read_table, so it stops short of a 5.

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

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

There is no statement of when to use this versus read_model_info, list_tables, or read_table, and no prerequisites (e.g., that a model must be open). Usage is only implied by the fact that it returns an overview.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds real value with the 'Gen only' restriction on the story parameters and the note that id-keyed entries are 'capped like read_table', but says nothing about return shape or how capping actually behaves.

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

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

Front-loads the key differentiator ('computed, not stored in a table') before the parameter breakdown, and every clause about the `what` values earns its place. The compressed 'what:' list is dense but readable.

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

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

For a read-only three-parameter tool with no output schema, the definition covers the main selection dimension and product restriction adequately. Minor gaps remain around the `limit` semantics and what the capping actually returns.

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

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

Schema coverage is 0%, so the description must carry the burden, and it does explain all five `what` values with concrete meaning plus the Gen-only constraint on two of them. It leaves `limit` (only alluded to via 'capped like read_table') and `product` unexplained, but those are lower-risk given the enums.

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

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

States a specific resource: model-wide computed information, explicitly contrasted with 'not stored in a table', which separates it from read_table/list_tables. An agent can tell what kind of data this returns without opening the schema, though the verb is only implied by the name.

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

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

The parenthetical glosses on each `what` value function as selection guidance for the main parameter, and 'not stored in a table' implicitly routes away from read_table. However, there is no explicit when-to-use/when-not statement and no direct routing to siblings like model_summary.

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

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

Beyond the readOnly/idempotent annotations, the description discloses two useful behaviors: limit is capped by the server's MIDAS_MAX_ROWS, and the reply reports the table's total record count so truncation is detectable. That is real operational context the annotations cannot convey.

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

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

Compact and front-loaded: the core purpose comes first, followed by parameter notes. The inline newlines make the parameter section slightly choppy, but no sentence is wasted.

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

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

With no output schema, the description should describe the return more fully; it only mentions the total-count field and truncation behavior. The undocumented product parameter and the absence of any return-shape details beyond the count leave it adequate but incomplete for a 4-parameter read tool.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains ids (filter to these records), limit (max records, server-capped) and illustrates table naming, but the required product parameter (enum gen/civil) is never explained, leaving a meaningful gap.

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

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

States a clear resource and scope: it returns the records of a single table in the open model, with concrete examples ("NODE", "DESIGN/STEEL/DSTL"). It does not explicitly differentiate itself from siblings such as list_tables, describe_table or result_table, so an agent must infer that this is the record-fetching call.

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

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

The table-path examples imply when the tool applies and the ids/limit notes hint at narrowed reads, but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives like result_table or list_tables. Usage is inferred rather than stated.

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

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

Annotations already cover read-only, idempotent, closed-world, so the bar is lower; the description still adds real behavior: nothing is exported to file, and rows beyond limit (capped by MIDAS_MAX_ROWS) are counted rather than returned. That truncation-and-count behavior is exactly the kind of non-obvious trait an agent needs before trusting the output.

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

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

The leading sentence front-loads purpose and the endpoint, then parameters are addressed in order with no filler. The table_type enumeration is long and partly redundant with the list_result_tables pointer, but each example conveys real domain meaning rather than restating the schema.

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

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

For a six-parameter, no-output-schema tool, the description covers the discovery path, parameter formats, and row-cap behavior, which is most of what is needed to call it correctly. The unmentioned product parameter and the absence of any note on return shape are the remaining gaps.

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

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

With 0% schema description coverage the description must carry the load, and it does for table_type (named examples), load_cases (suffix format with a concrete example), components (column names), keys (node/element ids), and limit (capped by MIDAS_MAX_ROWS). The required 'product' parameter (gen/civil enum) is never mentioned, leaving one documented-only-by-enum gap.

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

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

The first sentence names a specific verb and resource — retrieve one result table from the open model — and disambiguates from list_result_tables by noting it returns data rather than a catalog. It stops short of contrasting with siblings like show_result or read_table, which an agent could confuse it with.

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

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

It gives clear routing context: table_type comes from list_result_tables, and the model's load cases are found via read_table("STLD"), which tells the agent how to prepare a call. It does not state when to prefer show_result or capture_view instead, so it lacks explicit exclusions.

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

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

Goes well beyond the annotations (destructiveHint=true, not idempotent) by disclosing the exact destructive mechanism: NX overwrites the open document on disk, keeps a .bak, includes unsaved changes, and does so even when the analysis is then refused. It also flags the blocking-dialog failure mode, which an agent could not infer from structured fields.

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

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

Front-loads the action and the two-step flow before the caveats, and every sentence carries real information. The final sentence is slightly convoluted ("raise a Save As dialog that blocks NX, and is refused here") but not wasteful.

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

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

For a destructive, non-idempotent mutation with no output schema, the description covers the risky behavior, disk side effects, and preconditions thoroughly. It is still unclear what the preview step returns and how a token is obtained, which leaves a gap for a two-phase tool.

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

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

Schema description coverage is 0% for 2 parameters, so the description must compensate. It never explains what `product` values (gen/civil) mean or how `confirm_token` drives the preview→apply transition, where it comes from, or whether it can be reused — the phrase "preview, then apply" only hints at it.

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

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

States a specific verb and resource plus the underlying call ("Run the analysis in NX (POST /doc/ANAL)") and outlines a two-step preview-then-apply shape. It does not name or contrast with any sibling (e.g. apply_operations, show_result), so an agent gets the action but no explicit disambiguation.

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

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

Gives a clear usage sequence ("Two steps: preview, then apply") and a strong precondition/exclusion: the document must have been saved before and be visible in the NX window title, while a never-saved document is refused and would block NX with a Save As dialog. No alternative sibling tools are mentioned for when this should not be used.

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

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

Goes well beyond the annotations: it discloses that the original file is preserved, that the copy becomes the active document for the window, subsequent saves, and run_analysis, and that the filename is generated with a product-specific extension. What it leaves implicit is the mechanics of the confirm/preview step, e.g. that the token must come from the preview call and whether it expires.

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

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

Front-loads the core action and endpoint in the first line, then adds behavioral context. The 'Like Save As in NX' analogy and the long clause about window/later saves/run_analysis carry real information but are wordier than necessary.

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

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

For a two-parameter mutation with no output schema, this covers the essentials: what is created, where it goes, how it's named, what happens to the original, and why an agent would reach for it (priming a document for run_analysis). Nothing critical is missing to call it safely.

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

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

With 0% schema description coverage, the description compensates well: it maps the product parameter to its two enum values and their resulting extensions (.mgbx for Gen, .mcbz for Civil), and the 'preview, then apply' phrasing implies confirm_token gates the second step. It could be more explicit that confirm_token is the value obtained from the preview response.

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

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

States a specific verb and resource ('Save the model as a new file in the output folder') and even the backing endpoint (POST /doc/SAVEAS). It further disambiguates the intent by noting this is also the only route to give a never-saved document a file, so an agent can tell it apart from ordinary persistence in run_analysis.

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

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

Gives clear context: 'Two steps: preview, then apply' and 'also the way to give a never-saved document a file, which run_analysis needs.' That tells the agent when this tool is the right prerequisite for run_analysis. It stops short of explicit when-not guidance or naming a sibling that accomplishes the same result instead.

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

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

The annotations already declare destructiveHint=false and idempotent=true, but readOnlyHint=false is ambiguous for a tool that only changes what the window displays. The description resolves that by stating the window keeps showing the result afterward while the model and its results are not changed, which is exactly the state-effect detail the annotation cannot convey.

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

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

Front-loaded with the effect and return format, then a compact indented component table. The parenthetical POST /view/RESULTGRAPHIC and /view/CAPTURE implementation detail is the only line that doesn't clearly help an agent choose arguments.

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

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

Eight parameters and no output schema, but the description covers the return value (PNG), the side effect (window state), most parameter meanings, and the analysis prerequisite. It is nearly complete for a tool of this complexity, falling short only on the required 'product' parameter.

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

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

With 0% schema description coverage the description has to carry the load, and it mostly does: it enumerates the valid components per result type, gives load_case string formats with examples, explains show_values and deform_scale defaults, and caps width/height at 2000 pixels. The notable gap is 'product' (required, enum gen/civil), which is never mentioned.

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

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

The first sentence gives a concrete verb and outcome: display an analysis result in the NX window and return it as a PNG. That is clearly distinct from read_table/list_tables siblings, though it never names capture_view, the closest alternative, leaving the boundary between the two implicit.

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

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

It states a prerequisite ('Needs the analysis run in NX') and points the agent to read_table("STLD") for load_case names, plus the combination-suffix convention. What's missing is an explicit exclusion: nothing says when to use this instead of capture_view for the same window.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the mutation risk profile is known. The description earns credit for going beyond that: 'Any write discards the analysis results', the 50-record cap, read-back after applying, and tables that reassign ids ('trust "added", not the ids you sent').

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

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

It is front-loaded with the two-sentence summary and the records example arrives before the edge cases. Some sentences are crammed with parenthetical asides ('a load's load case or group, ...', '(midas-nx plan.validate)') that hurt scanability, though each carries real information.

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

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

For a destructive, nested-object, five-parameter write tool with no output schema, this covers refusal semantics, id reassignment, size caps, and result invalidation. The notable hole is the preview/apply handshake: the confirm_token is never tied to the stated two-step workflow, so an agent cannot tell how to complete the apply step.

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

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 the load and it only partly does. It explains 'records' well ({id: fields} with a NODE example) and defines the create/update split for 'mode', but 'confirm_token' — clearly the preview/apply token — and the 'product' enum (gen/civil) get no explanation at all.

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

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

'Create or update records in one /db or /DESIGN table' gives a specific verb set plus a bounded resource, and it separates the tool from read-only siblings (read_table, describe_table) and from delete_records. The two-step 'preview, then apply' framing further pins down what the tool actually does.

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

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

It gives clear operational rules: create refuses existing ids, update refuses missing ids, with the explicit exception of record '1' in DCO/DCTL/LLRF/LMRR/SRDF. It routes the agent to describe_table and read_table for field definitions, but never mentions when to prefer this over the sibling apply_operations, which is the closest alternative.

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