Skip to main content
Glama

get_construction_history

Read-only

What a construct was BUILT from: the recorded operations, the molecules they consumed, how many rounds deep the build goes, and which of the 5 sources the record came from.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many steps to return, oldest first. All of them when omitted.
queryNoFree text over the operation, the recorded command, its info field, the process id and name, and every molecule the step names — the panel’s step filter. Composes with `molecule` rather than replacing it.
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
documentNoFile id or name. The focused document when omitted, exactly as the panel.
moleculeNoKeep only the steps that produced or consumed this molecule, by its recorded name — the panel’s graph-node filter. Names that are not in the history are refused with the list of the ones that are.

Output Schema

NameRequiredDescriptionDefault
depthYeslongest chain of operations from a starting material to the construct — 1 is a single round, and more means it was built on builds
graphYesthe lineage itself: `levels`, the molecule names by round with the starting materials at 0, and `edges`, every parent → product pair. This is the Graph and Lineage tabs’ own derivation, and without it a caller holding `steps` would have to rebuild it from the recorded commands
stepsYesthe recorded operations, oldest first, with their inputs, products and enzymes. A step that records a coordinate also carries `window`: the bounds as the file writes them, the molecule they are an index INTO (never this one), and the intervals of this record they project onto through the map QUEEN writes into it — empty, with a stated reason, when those bases are not in the finished molecule
totalYesrecorded operations in the whole build, before any filter
inputsYesmolecules the history starts from: nothing recorded produced them
originYesthe record this was decoded out of — NOT always the document asked for: a file with no history falls back to the project, and this names what actually answered
sourceYeswhich of the 5 records this came from: the workbench log, a SnapGene .dna reaction graph, a QUEEN build script, an OpenCloning strategy, or an SBOL 2/3 construction record
enzymesYesthe enzymes this build cut with, as the history records them
matchedYeshow many steps the `molecule`/`query` filters kept — the panel prints `matched/total`, and collapsing the two would make "12 of 12" and "12 of 76" the same answer
cautionsYesonly what THIS history earned — a step the decoder could not follow, products a reaction could not have made, or a limitation of the source format. Empty is the healthy case
protocolYesthe same numbered bench-recipe protocol the panel renders and exports
conclusionYesone generated sentence: how much was recorded, over how many rounds, from how many starting materials, and on whose authority. The same `conclusionOf` the panel headlines
derivationYesthe chain behind the answer: this history ← decoder ← read from ← graded against. The last link is absent for a build recorded here, which has no oracle behind it
process_flowYesthe build as named processes: `groups` (the author’s process names, each with its operations in execution order), `operations` (the quinable call, its depth, what it consumed and produced, and its recorded arguments), and `depth`. Absent for a record that carries no re-executable command list — only a QUEEN history does — and `unavailable` with the upstream reason for the one build shape QUEEN cannot draw itself

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

The annotations already establish that this is a safe, read-only, closed-world operation. The description adds useful scope about what history data is exposed, but it does not add operational behavior such as default document handling, filtering behavior, or error conditions beyond what the schema already covers.

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

Conciseness5/5

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

The description is a single front-loaded sentence with no redundant wording. The colon-separated list efficiently communicates the main components of the returned construction history.

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

Completeness3/5

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

The tool has six parameters, nested inputs, and an output schema, so much of the structural detail is already covered elsewhere. However, the description does not orient the agent on when to use this tool versus related construction or history tools, leaving a meaningful routing gap.

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?

The input schema has 100% description coverage, including detailed meanings for limit, query, _files, _subject, document, and molecule. The description does not add parameter-level meaning beyond that, so the baseline score of 3 applies.

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

Purpose4/5

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

The description clearly identifies the resource as a construct's build provenance and names the specific history components returned: operations, consumed molecules, build depth, and source. It stops short of distinguishing this tool from closely related siblings such as history_protocol, record_composition, or export_construction_record.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool, when not to use it, or which sibling to choose for related tasks. Usage is only implied by the name and the provenance-focused description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources