Skip to main content
Glama
Sign In
Construct

Construct

by rtmandreyev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

construct_netlogo_draw

Read-onlyIdempotent

Turns a NetLogo JSON Lines run into a drawable scene, choosing space-time, network-time, phase, field, pulse, or auto views and adding legend, replay clock, and counts for later compilation or export.

Instructions

A construct of a recorded NetLogo run (the JSON Lines a run writes), computed from the data alone, with its legend, how-to-read lines, replay clock and counts, and a data lock. Views: space-time (moving agents), network-time (spreading on a network; give state), phase (two reporters in a cycle), field (spreading over patches), pulse (turtles switching a state on and off: how many at once, tick by tick), auto (the one the data suits). Moving agents and pulses are drawn over the window where their order formed when it forms early (window: auto, whole, or a tick). Optional: an art-direction layer (art: views, labels, milestones; never the data), solid (spheres, tubes, a surface, for a 3D model) and materials (the run's own colours, for construct_export). Compile or export the scene with the other tools.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recording": "<recording>",
      "view": "<view>"
    },
    "name": "construct_netlogo_draw"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNo
zNo
artNoan art-direction layer (docs/NETLOGO.md: credit, title, summary, looks, parts, facts, annotations, presentation, animation, reading, legend)
timeNo
viewYes
solidNo
stateNo
titleNo
changeNo
colorsNorun (default): the run's own NetLogo colours; house: Construct's tones
levelsNo
smoothNo
windowNospace-time and pulse: auto (default), whole, or the tick to end at
landmarksNothe moments worth marking, from the counts (on by default)
materialsNo
recordingYesthe run's JSON Lines (a larger run: record with every > 1, or draw it with the command line)
max_agentsNo
resolutionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavior beyond that: the construct is 'computed from the data alone', the art layer 'never [touches] the data', and there is a 'data lock'. It does not say where the scene goes, whether it is persisted or cached, or what happens with very large recordings beyond the schema's maxLength note.

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

Conciseness3/5

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

Everything is packed into one long, parenthesis-laden sentence; the purpose is front-loaded and nothing is strictly redundant, but the absence of sentence breaks or list structure makes it slow to parse for an 18-parameter tool.

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?

For a tool of this complexity with no output schema and 18 parameters, the definition covers the conceptual model (views, art layer, window) reasonably but omits the crucial contract: what is returned or produced by 'draw', and how the result is handed to construct_compile or construct_export. That missing output hand-off is the main completeness 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?

Schema description coverage is only 28% across 18 parameters, so the description is carrying weight and does explain view, state, window, art, solid and materials in meaningful terms. But a large set of parameters — x, z, time, change, title, levels, smooth, landmarks, max_agents, resolution — get no semantic treatment in either place, so the gap is only partly closed.

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 names a specific resource and action: it builds a construct (scene) out of a recorded NetLogo run, enumerating what is included (legend, how-to-read lines, replay clock and counts, data lock) and the six view types. It also distances itself from siblings with 'Compile or export the scene with the other tools.' The phrasing 'A construct of a recorded NetLogo run' is noun-heavy rather than a clean verb, which keeps it from a 5.

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

Usage Guidelines3/5

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

There is view-selection guidance ('auto (the one the data suits)', network-time requires state, window only applies to space-time and pulse) and a routing hint that compilation/export happen elsewhere. However, no sibling is named, and there is no explicit statement of when to call this versus construct_netlogo_instrument or construct_compile, leaving usage largely implied.

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