Atlasly

Start Site Package

run_site_package

Purpose: request a background Atlasly site package for a resolved site. When to use: only after the user explicitly asks to start a package and connects an account with atlasly.site_package.run permission. Inputs: address, optional search radius in metres and an optional existing project_id; account ownership and entitlement are enforced by the package service. Side effect: submits a new job to the Atlasly package service, which may retrieve independently published source data. Repeated calls can create separate jobs. Returns: accepted job_id and an Atlasly link, not a finished report or download. Use get_job_status to inspect completion, failed steps and reported files. Source coverage, export formats, delivery time and native import are unverified at acceptance. No global planning clearance, terrain, 3D or guaranteed CAD/GIS deliverable. For an immediate bounded buildings/roads export, use export_site_context instead. 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": "run_site_package"
  }
}

Input Schema

Name	Required	Description
`address`	No	Site address or postcode, with town and country outside the UK. Alternatively pass site_ref from an earlier result; do not send both for different locations.
`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.
`project_id`	No
`radius_meters`	No	Search radius in metres around the site. Requests above the caller's limit (1,000 m without an account, 2,000 m with one) are reduced or rejected.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), it discloses the real side effect — a new job is submitted, repeated calls create separate jobs, and source data may be independently published. It also manages expectations by flagging that source coverage, export formats, delivery time and native import are unverified, and that no guaranteed CAD/GIS deliverable exists. Minor gap: no mention of rate limits or per-call cost, though the accounting/permission enforcement is noted.

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?

Well-structured with labelled sections (Purpose, When to use, Inputs, Side effect, Returns, Chaining) and front-loaded intent. It is dense but nearly every sentence carries distinct information; the list of things it is *not* (terrain, 3D, planning clearance) is slightly verbose but serves as useful expectation-setting for a costly job submission.

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?

For a background-job mutation with an output schema and annotations, the description covers preconditions, side effects, return shape, follow-up tool, scope exclusions and chaining — everything an agent needs to call it correctly. Nothing material is missing.

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 coverage is 75%, so the schema already documents radius limits and site_ref chaining in detail. The description adds framing by listing inputs (address, optional radius in metres, optional existing project_id) and by explaining that account ownership and entitlement are enforced by the service. However, the 'Inputs' line omits site_ref as an accepted alternative, leaving it only implied by the chaining sentence.

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 — 'request a background Atlasly site package for a resolved site' — and immediately bounds what the result is ('accepted job_id and an Atlasly link, not a finished report or download'). It also distinguishes itself from siblings by naming get_job_status for completion and export_site_context for an immediate bounded export.

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?

Explicit preconditions are given: only after the user explicitly asks to start a package and has an account with atlasly.site_package.run permission. It names two concrete alternatives with the conditions that select them (export_site_context for immediate bounded buildings/roads export, get_job_status for inspecting completion or failures).

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?