Atlasly

Compare Saved Design Options

compare_design_options

Read-onlyIdempotent

Read the connected user's active saved Canvas options for one owned development. Use project_id from list_developments. Omit option_ids to choose available options; supply exactly two different IDs to compare immutable captured versions. Recomputes early design quantities from saved geometry and assumptions. No planning verdict, GIA, surveyed area, overlap correction or preferred option. Requires the existing projects permission. Never edits designs. Chaining: every response returns site_ref; pass it unchanged into another Atlasly tool to reuse the canonical site, coordinates, boundary confidence, LPA, evidence links, and project context.

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": "compare_design_options"
  }
}

Input Schema

Name	Required	Description
`site_ref`	No	Canonical site_ref returned by any previous Atlasly tool. Pass it unchanged to chain the same resolved site into this call; address, search_area, or project_id will be filled from it when omitted.
`option_ids`	No
`project_id`	No

Output Schema

Name	Required	Description	Default
`query`	No
`status`	Yes
`details`	No
`message`	No
`sources`	Yes
`headline`	Yes
`site_ref`	Yes
`retryable`	No
`error_code`	No
`atlasly_link`	Yes
`error_source`	No
`human_message`	No
`key_data_points`	Yes
`top_constraints`	Yes
`confidence_notes`	Yes
`executive_summary`	Yes
`next_best_actions`	Yes
`top_opportunities`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive behavior, yet the description still adds real context: it never edits designs, requires the existing projects permission, recomputes early design quantities from saved geometry, and enumerates what is deliberately not produced (no planning verdict, GIA, surveyed area, overlap correction, preferred option). The gap is that it does not say what happens when the two options lack comparable inputs or whether recalculation can fail.

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?

Purpose and scope are front-loaded, then the parameter branches, then exclusions, then chaining — a sensible order with no filler. The chaining sentence is long and dense and could be split, but every clause carries information an agent needs.

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?

With three loosely-required parameters, a deeply nested site_ref, and an output schema present, the description covers the operational essentials: permission prerequisite, comparison semantics, non-returned metrics, and the site_ref chaining contract. Return-value detail is correctly left to the output schema.

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 description coverage is only 33%, with only site_ref documented, so the description must compensate and largely does: it explains the omit-vs-two-ID semantics of option_ids, the 'different' constraint beyond the schema's min/max 2, and where project_id originates. It does not clarify the site_ref/project_id interaction when both are supplied, which the schema description only partly covers.

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?

The first sentence names a specific verb and resource with scope: read the connected user's active saved Canvas options for one owned development. It also distinguishes itself from list_developments by pointing to it as the source of project_id, and the exclusion list makes clear it is not a consenting/verdict tool.

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?

It gives explicit branching guidance: omit option_ids to choose available options, supply exactly two different IDs to compare captured versions, and take project_id from list_developments. It also states the reversal (immutable captured versions vs. live options) and the chaining rule, leaving little to inference.

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

All Atlasly 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.

Resources

Need Help?