Skip to main content
Glama

create_scene_interpretation_plan

Binds host-AI scene-role rankings to immutable graph and visual hashes, creating a traceable interpretation plan for CAD-to-GIS scene validation.

Instructions

Bind host-AI scene-role rankings to immutable graph and visual hashes.

Input Schema

NameRequiredDescriptionDefault
producerNo
graph_pathYes
assignmentsYes
output_pathNo
visual_manifest_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a write/create operation and hints at immutability via 'immutable graph and visual hashes', but it does not state that a plan file is produced, where output_path writes, whether existing files are overwritten, what inputs must pre-exist, or any failure/side-effect behavior.

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?

The single sentence is front-loaded and free of filler, but it is too terse for a 5-parameter creation tool with no annotations. Conciseness is not the problem; under-specification is.

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

Completeness2/5

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

Given the absence of annotations, a 0% schema description coverage, and a create-style operation, the description is not complete enough. It omits prerequisites, plan artifact semantics, validation relationship, output behavior, and most parameter meanings, even though an output schema covers the return shape.

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

Parameters2/5

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

Schema description coverage is 0% across 5 parameters. The description loosely gestures at graph_path and visual_manifest_path ('graph and visual hashes') and assignments ('scene-role rankings'), but it does not explain the format, required contents, producer semantics, or the output_path default. Two parameters are entirely unaddressed and the mapped ones remain ambiguous.

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

Purpose3/5

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

The description states a specific operation ('Bind ... rankings to ... hashes'), but it is heavily jargon-laden and never says that it creates a scene interpretation plan artifact or how it differs from the sibling validate_scene_interpretation_plan. An agent can infer the broad intent, but the core resource ('plan') is only available from the tool name, not the description.

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 when-to-use guidance, no prerequisites (e.g., needing an existing graph, visual manifest, or prior scene-role ranking step), and no mention of the sibling validation tool or any alternative. The agent is left to infer the entire workflow context.

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