Skip to main content
Glama
Sign In
Construct

Construct

by rtmandreyev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

construct_diagnose

Read-onlyIdempotent

Validates v2 scene or parameter documents, listing each issue with its JSON path, code, fix hint, and repair text to return to the generating model.

Instructions

Check a v2 scene or parameter document (contract construct/0.2): every problem with a JSON path, a code and a fix hint, plus repair_text to send back to the model that wrote it. Give text (the model's raw answer) or document (parsed JSON).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "construct_diagnose"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNo
documentNoa construct-scene (version 2) or a construct-params document

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds genuine value beyond them by disclosing the return shape (all problems with path/code/fix hint plus a repair_text payload), which matters because there is no output schema.

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?

Two sentences, purpose front-loaded, no filler. The parenthetical contract identifier sits mid-sentence and slightly interrupts the flow, but every clause carries information the agent needs.

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

Completeness4/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 correctly spends its words on what comes back (problem list with paths/codes/hints and repair_text), which is the right emphasis. The remaining gap is operational: it doesn't say whether problems are returned as data versus raised as errors, nor whether exactly one of text/document must be given.

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?

Schema coverage is 50% — `document` is described in the schema but `text` is not. The description compensates by defining `text` as the model's raw answer and `document` as parsed JSON, adding real meaning over the bare schema. However, it never states that the two are alternatives or that at least one is required (0 required params), leaving a genuine ambiguity.

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: 'Check a v2 scene or parameter document (contract construct/0.2)'. It goes on to enumerate exactly what the check yields (per-problem JSON path, code, fix hint, repair_text), which distinguishes it from generation tools like construct_compile and construct_print without needing to name them.

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

Usage Guidelines4/5

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

Gives concrete invocation context by telling the caller to supply `text` (the model's raw answer) when it has unparsed output, or `document` (parsed JSON) when it already has structured input. It stops short of stating when to prefer this over a sibling validator/compiler or what happens if both/neither is supplied.

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