ARCNM

Attach Drawing

attach_drawing

Destructive

Give a drawing (PDF, PNG or JPEG) to the part it belongs to, whatever the two files are called. Before a run: precheck_id from precheck_part and the row's component_key from get_precheck (or assembly, for the assembly's own drawing), with data_source_id of a drawing the precheck holds or the file as base64. The drawing goes with that part when upload_and_quote starts the precheck; attaching before the start is free and bills nothing. After a run: calculation_id of the part's own calculation (for an assembly, a component's) and the drawing. It becomes that part's drawing and, with run true (the default), the part is priced again as a new calculation, billable only if it succeeds; the same drawing again changes nothing. By default (apply=false) it only plans and attaches nothing; apply=true attaches. Returns where the precheck's drawings go, or the new calculation.

Input Schema

Name	Required	Description
`run`	No	With calculation_id: price the part again with the drawing (default true; billable only if it succeeds). False attaches only.
`apply`	No	False (the default): plan only, read the target and say what would change; nothing is attached. True: attach.
`precheck_id`	No	Before the start: the precheck, as precheck_part returns it. With component_key; not with calculation_id.
`component_key`	No	With precheck_id: the part the drawing belongs to, a row's component_key from get_precheck, or assembly for the assembly's own drawing.
`calculation_id`	No	After a run: the calculation of the part, as upload_and_quote, quote_part or list_calculations return it (for an assembly, a component's own). Not with precheck_id.
`data_source_id`	No	A drawing already stored: with precheck_id one the precheck holds (its drawings in get_precheck), with calculation_id a drawing of this organization that no unstarted precheck holds. Not with drawing_file_b64.
`drawing_file_b64`	No	The drawing itself, a PDF, PNG or JPEG as base64 (or a data: URI). With drawing_filename; not with data_source_id.
`drawing_filename`	No	The file name of drawing_file_b64 with its extension, e.g. ZX-0001_A.pdf.
`drawing_content_type`	No	MIME type of drawing_file_b64, when known.

Output Schema

Name	Required	Description
`target`	Yes	`precheck`: placed before the start. `calculation`: attached to a calculated part.
`applied`	Yes	False: a plan only, nothing was attached. True: the drawing was attached.
`changed`	No	False when this drawing already was the part's drawing: nothing was attached and nothing runs.
`drawings`	No	Every drawing the precheck holds, and where each goes.
`revision`	No	The precheck's revision, to start it with.
`next_step`	Yes	What happens next.
`precheck_id`	No
`prices_again`	No	For a calculated part: whether it is priced again — a new calculation, or a component's own in place. In a plan, what apply=true does.
`component_key`	No	The part the drawing goes to on the precheck, or `assembly`.
`calculation_id`	No
`data_source_id`	No	The drawing, as stored.
`precheck_status`	No	The precheck's status: `received` while a new drawing's title block is read, `ready` once answered.
`new_calculation_id`	No	The calculation that prices the part with this drawing, when run is true and the drawing changed.
`rerun_calculation_id`	No	For a component of an assembly: its own calculation, priced again in place.
`new_calculation_status`	No	Its status: `queued` is a run, `succeeded` an identical earlier run answering it unbilled, `blocked` a run held for quota.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: attaching before the start is free, re-pricing is billable only on success, and apply=false is a dry run. The claim that 'the same drawing again changes nothing' sits in mild tension with idempotentHint=false, but it is a scoped nuance rather than a contradiction, since attaching a different drawing does mutate state.

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?

Front-loads the purpose, then organizes by 'Before a run' / 'After a run' phases, which matches how an agent reasons about the call. It is a dense single block of ~180 words; a bulleted split would be easier to scan, but almost every clause carries information.

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?

Covers both invocation modes, file sourcing, default dry-run, billing implications, and what the call returns, for a 9-parameter tool with annotations and an output schema. Nothing an agent needs to call it correctly appears to be missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining which parameters pair together (precheck_id + component_key, calculation_id alone, data_source_id xor drawing_file_b64) and where each value comes from. It adds cross-parameter guidance the schema does not encode.

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?

States a specific verb and resource ('give a drawing ... to the part it belongs to') and immediately names the file types accepted. It also splits the operation into its two distinct modes (before a run vs after a run), which is what actually distinguishes it from siblings like upload_and_quote or precheck_part.

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?

Explicitly names when to use each path: 'Before a run: precheck_id from precheck_part and the row's component_key from get_precheck', and 'After a run: calculation_id'. It also states the alternative for supplying the file (data_source_id vs base64) and the default plan-only behavior, leaving little to infer.

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

All ARCNM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.