Skip to main content
Glama

Create saved place

well_create_saved_place

Save a place for the person who asks: a name and a point, such as the office, a client's site or a shop. The place belongs to that member alone.

Use this tool only when the person asks to save, keep or remember a place or an address: "Save this address", "Garde ce lieu", or "2" in answer to a question whose second choice was to save the address. A complete order is the yes: the place is saved at once, with no card. Never save a shared location the person did not ask to save.

REQUIRED: label, latitude, longitude. Take the latitude and the longitude exactly as the shared location states them, and never work them out from a name or an address. The label is the name the person gives, else the place name the location carried, else its address; with none of these, ask the person for a short name first and save nothing. OPTIONAL: radius_meters, only when the person names a distance.

A member holds at most 100 saved places; past that the call fails and nothing is saved. well_list_saved_places lists them, well_update_saved_place changes one and well_delete_saved_place deletes one.

Returns { success: true, saved_place } on success, or { success: false, error } on failure.

Input Schema

NameRequiredDescriptionDefault
labelYesThe place's name as the person gives it, or the place name or the address the shared location carried. Never the coordinates.
latitudeYesThe latitude, in decimal degrees (-90 to 90), as the shared location states it.
longitudeYesThe longitude, in decimal degrees (-180 to 180), as the shared location states it.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
radius_metersNoHow close counts as being at the place, in meters, from 150 to 5000. Default 200. Pass it only when the person names a distance.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
codeNo
errorNo
successYes
reply_linesNo
saved_placeNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
near_candidatesNo
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
near_candidates_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / code
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / near_candidates
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "company_id": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "company_id",
      +      "name"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / near_candidates_truncated
      Added value: +{
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / reply_lines
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations say only readOnly=false, destructive=false, openWorld=false; the description adds real behavior beyond them: the save is immediate with no confirmation card, the place is per-member, the 100-place quota makes the call fail with nothing saved, and the return shape is success/error. These are exactly the facts an agent needs before a non-idempotent-feeling write.

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-loads purpose, then usage, then REQUIRED/OPTIONAL parameter rules – a genuinely useful structure. Some content is redundant with the schema (the radius_meters rule is stated almost identically in both places), which keeps it short of a 5.

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?

Covers everything an agent needs for an 8-parameter write with an output schema: trigger conditions, exclusions, label fallback, coordinate sourcing, quota failure mode, and confirmation behavior. Return values are documented in the output schema and in the description, so 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 already 100%, but the description still adds procedural meaning the schema cannot: take latitude/longitude verbatim from the shared location rather than deriving them, use the label fallback chain (person's name → place name → address → ask), and pass radius_meters only when a distance is named. It says nothing about workspace_id, conversation_id or idempotency_key, which stay schema-only.

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 a place for the person who asks: a name and a point' – with concrete examples (office, client's site, shop) and a scoping fact ('belongs to that member alone'). It also names the three siblings that list, change and delete saved places, so an agent can tell it apart without opening any 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 explicit positive triggers with example utterances in two languages ('Save this address', 'Garde ce lieu') and the reported-input case ('2' answering a question whose second choice was to save). It also gives an explicit exclusion ('Never save a shared location the person did not ask to save') and names the alternatives (list/update/delete). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources