Atlasly

Enable Site Watch

enable_site_watch

DestructiveIdempotent

Purpose: save enabled Site Watch settings for an owned Atlasly development after the user explicitly requests monitoring. Requires a connected account with atlasly.site_watch.write permission. Inputs: project_id from list_developments, optional checks, weekly/monthly frequency and radius in metres. Replaces that user's existing watch configuration, including previous choices for omitted fields; omitted fields reset to the defaults below. Present the replacement and defaults for user confirmation before calling. Repeating the same settings is idempotent. Planning, flood and competitive checks default to true; web_search defaults to false. The configured monitoring service may subsequently check independently published planning, flood and web sources. Returns saved settings and an Atlasly link only. This call does not perform a source check, verify source coverage, confirm scheduling or promise future alerts. Review completed checks and delivery in Atlasly. Never enable monitoring without the user's explicit request. 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": "enable_site_watch"
  }
}

Input Schema

Name	Required	Description
`checks`	No
`radius_m`	No
`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.
`frequency`	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.9/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the call replaces the user's existing configuration and resets omitted fields to defaults (reinforcing destructiveHint), that repeat calls are idempotent, the required atlasly.site_watch.write permission, the exact return payload, and four explicit non-behaviors (no source check, no coverage verification, no scheduling confirmation, no alert promise).

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?

Front-loaded with "Purpose:" and sectioned by "Inputs:" and "Chaining:", with no filler sentences. It is dense and slightly overlong for a single block, but each sentence contributes a distinct constraint or default.

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 destructive, open-world mutation with five loosely documented parameters and nested objects, the description covers permissions, replacement semantics, defaults, confirmation, idempotency, output scope, and chaining. Little that an agent needs to call it safely is missing.

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

Parameters5/5

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

Schema coverage is only 20%, and the description compensates fully: it supplies the defaults the schema lacks (planning/flood/competitive true, web_search false), explains frequency options as weekly/monthly, states radius is in metres, and sources project_id from list_developments. This is meaning the schema alone does not convey.

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: "save enabled Site Watch settings for an owned Atlasly development after the user explicitly requests monitoring." This is distinguishable from every sibling (analysis/inspection tools) without opening a schema, and the scope (per-user watch configuration) is explicit.

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?

Gives explicit when-to-use (user explicitly requests monitoring), an explicit prohibition ("Never enable monitoring without the user's explicit request"), a confirmation workflow ("Present the replacement and defaults for user confirmation before calling"), and points to list_developments for project_id.

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?