mcp

deleteServiceArea

DestructiveIdempotent

Stop serving a territory

Soft-deletes the service area: it disappears from listServiceAreas and stops counting for coverage immediately. Technician assignments to it are left in place but no longer grant coverage.

The consequence is easy to underestimate: technicians whose only coverage was this area become unmatchable for addresses inside it. Jobs already assigned keep their technician, but any re-plan (reassign, board move, confirm of a pending job, the slot picker) can find no feasible crew there. Before deleting, re-check listCrewCandidates on upcoming jobs in that territory.

If you are reshaping coverage rather than withdrawing from it, edit the polygon or postal/city fields with updateServiceArea instead; that keeps the area and its technician assignments working.

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": {
      "id": "<id>"
    },
    "name": "deleteServiceArea"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Service Area ID

Output Schema

Name	Required	Description
`data`	No	The response payload. Omitted on error unless the error carries structured data.
`errors`	No	Field-level validation details; present only for VALIDATION_ERROR responses.
`message`	No	Human-readable message ("Success" or an error description), localized via the X-Locale header.
`error_code`	No	0 on success; a stable string error code on failure (e.g. CUSTOMER_NOT_FOUND).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive=true, but the description goes well beyond that: it clarifies this is a soft delete, specifies the area disappears from listServiceAreas immediately, explains that technician assignments remain but stop granting coverage, and details the downstream consequence (unmatchable technicians, re-plans failing). This is exactly the kind of non-obvious behavioral context annotations cannot convey.

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?

The core action is front-loaded in the first sentence, followed by consequences and the alternative path. It runs four paragraphs, which is long, but each block carries non-redundant information (soft-delete semantics, blast radius, sibling routing), so little is wasted.

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?

An output schema exists so return values need not be explained, and the description fully covers effect, side effects, and the decision to use it versus updateServiceArea. Nothing an agent needs to invoke it safely is missing.

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?

Only one parameter, whose schema description coverage is 100% ('Service Area ID' uuid). The description adds no further meaning to the id parameter itself, so the baseline of 3 applies since the schema fully documents it.

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+resource ('Stop serving a territory', 'Soft-deletes the service area') and distinguishes itself from the sibling updateServiceArea by contrasting withdrawal vs. reshaping coverage. An agent can tell exactly what this does and how it differs from the nearest alternative.

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?

Explicitly contrasts when to delete versus when to edit with updateServiceArea ('If you are reshaping coverage rather than withdrawing from it...'). It also prescribes a pre-delete check ('re-check listCrewCandidates on upcoming jobs'), naming the alternative tool directly.

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

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