SimpleDock

Update location details

update_location_details

DestructiveIdempotent

Edit a location's name, address, timezone, or booking-page URL. Omitted fields are left unchanged. slug sets the public link /book/{slug}: 3+ lowercase letters, numbers, and hyphens; a slug another facility uses is a conflict. Changing it breaks links already sent to carriers. For scheduling rules use update_location_settings. Returns the location with its bookingPageUrl. Requires scope locations:write (Admin role).

Input Schema

Name	Required	Description
`zip`	No	Postal code.
`city`	No	City.
`name`	No	Facility name.
`slug`	No	Booking-page path segment, e.g. acme-dallas.
`state`	No	State or region, e.g. TX.
`address`	No	Street address.
`country`	No	Two-letter ISO country code, e.g. "US" or "AU".
`timezone`	No	IANA timezone, e.g. "America/Chicago".
`locationId`	Yes	Location id, from list_locations.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / country

Added value: +{
+  "description": "Two-letter ISO country code, e.g. \"US\" or \"AU\".",
+  "type": "string"
+}

Changed7 schema fields changedOct 15, 2026
- addedInput schema / properties / address / description
```
Added value: +"Street address."
```
- addedInput schema / properties / city / description
```
Added value: +"City."
```
- addedInput schema / properties / locationId / description
```
Added value: +"Location id, from list_locations."
```
- addedInput schema / properties / name / description
```
Added value: +"Facility name."
```
- changedInput schema / properties / slug / description
```
Previous value: -"e.g. acme-dallas"New value: +"Booking-page path segment, e.g. acme-dallas."
```
- addedInput schema / properties / state / description
```
Added value: +"State or region, e.g. TX."
```
- addedInput schema / properties / zip / description
```
Added value: +"Postal code."
```
First observedOct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag this as destructive and idempotent, but the description adds material context beyond them: omitted fields are unchanged, a duplicate slug is a conflict, changing the slug breaks already-sent carrier links, and the call requires locations:write (Admin). It even documents the return value ('the location with its bookingPageUrl').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is dense and front-loaded: purpose first, then omission semantics, then slug rules and the destructive consequence, then the alternative tool, return value, and scope. Every sentence adds information; there is no filler.

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 mutation tool with annotations but no output schema, the description covers the missing pieces an agent needs: auth scope, idempotency behavior (omitted fields unchanged), destructive consequence of slug changes, conflict rule, return value, and a routing alternative. Nothing material is left out.

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 100%, so most parameter documentation is already carried by the schema; a baseline of 3 would apply. The description adds meaningful semantics for the trickiest field, 'slug' (format, uniqueness conflict, and link-breaking consequence), but does not elaborate the other eight fields beyond their schema descriptions.

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 ('Edit a location's...') and enumerates the editable fields. It also explicitly distinguishes itself from the sibling tool update_location_settings, so an agent can route correctly without opening either schema.

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 clear when-to-use guidance and an explicit alternative: 'For scheduling rules use update_location_settings.' It also states the omitted-fields behavior, slug constraints, conflict condition, and required scope, 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 SimpleDock 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?