Skip to main content
Glama

live_places

Read-onlyIdempotent

Show document places as clickable buttons so writers can jump the cursor or select a paragraph in Word or LibreOffice without an assistant turn.

Instructions

Show the user a list of places as clickable buttons: in a client that renders MCP Apps, a click moves Word's or LibreOffice's cursor there (mode cursor) or selects the paragraph (mode select) by calling live.select, with no assistant turn. Each place has a label and an at address and/or a find_phrase from para.locate. Use it to walk a writer through findings; live.select jumps to one place directly. Other clients just get the list back. Read-only.

Input Schema

NameRequiredDescriptionDefault
docYesPath to the document, or the file name of one open in a live app.
modeNoWhat a click does: `cursor` (default) puts the cursor at the place's start; `select` selects its paragraph.
engineNoAlways the live engine; may be left out.
placesYesThe buttons, in order: a `label` and `at` or `find_phrase` each (with both, `find_phrase` is tried when `at` fails).

Output Schema

NameRequiredDescriptionDefault
okYesAlways true on success.
opYesThe operation that ran.
apiYesAPI version (1.0).
docNoThe document read or written: path, sha256 and paragraph count.
nextYesCursor for the next page (pass as cursor), or null.
resultYesWhat the operation returns.
warningsYesThings to know about the result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "api": {
      +      "description": "API version (1.0).",
      +      "type": "string"
      +    },
      +    "doc": {
      +      "description": "The document read or written: path, sha256 and paragraph count.",
      +      "properties": {
      +        "characters": {
      +          "description": "text.normalize of a text string: its length.",
      +          "type": "integer"
      +        },
      +        "paragraphs": {
      +          "description": "Body paragraphs.",
      +          "type": "integer"
      +        },
      +        "path": {
      +          "description": "Path of the document.",
      +          "type": "string"
      +        },
      +        "sha256": {
      +          "description": "sha256 of the file (pass as expect.sha256 to a write).",
      +          "type": "string"
      +        },
      +        "source": {
      +          "description": "A .txt/.md/.odt source's format, encoding and split mode; \"text\" for a text string (text.normalize).",
      +          "type": [
      +            "object",
      +            "string"
      +          ]
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "next": {
      +      "description": "Cursor for the next page (pass as cursor), or null.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "ok": {
      +      "description": "Always true on success.",
      +      "type": "boolean"
      +    },
      +    "op": {
      +      "description": "The operation that ran.",
      +      "type": "string"
      +    },
      +    "result": {
      +      "description": "What the operation returns.",
      +      "properties": {
      +        "doc": {
      +          "description": "The document, as given.",
      +          "type": "string"
      +        },
      +        "mode": {
      +          "description": "cursor or select: what a click does.",
      +          "type": "string"
      +        },
      +        "places": {
      +          "description": "The places, as given.",
      +          "items": {
      +            "description": "A place.",
      +            "properties": {
      +              "at": {
      +                "description": "Paragraph address, p<n>#<fingerprint> (story-prefixed in notes/headers).",
      +                "type": "string"
      +              },
      +              "find_phrase": {
      +                "description": "Find phrase from para.locate.",
      +                "type": "string"
      +              },
      +              "find_phrase_across": {
      +                "description": "previous or next, from para.locate.",
      +                "type": "string"
      +              },
      +              "label": {
      +                "description": "Button label.",
      +                "type": "string"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "doc",
      +        "mode",
      +        "places"
      +      ],
      +      "type": "object"
      +    },
      +    "warnings": {
      +      "description": "Things to know about the result.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "api",
      +    "ok",
      +    "op",
      +    "result",
      +    "warnings",
      +    "next"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changedv0.1.3
    • changedInput schema / properties / places / items / properties / find_phrase / description
      Previous value: -"A `locate` find phrase; used when `at` is missing or stale."New value: +"A `para.locate` find phrase; used when `at` is missing or stale."
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/closed-world, so the description adds the valuable side-effect context: in a rendering client a click performs an in-editor jump with 'no assistant turn', while other clients just receive the list. This is genuine behavioral disclosure beyond the structured hints.

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 the core purpose in the first clause, then layers client behavior, data shape, and the sibling alternative. Single dense paragraph with no filler, though the nested clauses make it mildly harder to scan than a bulleted form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full annotation/schema coverage, the description only needs to add call-time semantics, which it does via the mode behavior and the client-dependent click effect. Nothing critical an agent needs to invoke it correctly 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?

Schema description coverage is 100% and every parameter is documented in the schema itself, including mode, engine, at/find_phrase, and the at-vs-find_phrase fallback. The description only restates that each place has a label plus an at or find_phrase, adding little beyond the heavy schema lifting, so baseline 3 applies.

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 ('Show the user a list of places as clickable buttons') and differentiates from the sibling live_select by noting it jumps to one place directly versus this tool's list-at-once behavior. An agent can distinguish it from para_locate/para_list 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the use case ('walk a writer through findings') and names the alternative ('live.select jumps to one place directly'), plus notes behavior for non-MCP-App clients. It doesn't spell out when NOT to use it, but the routing to live_select is clear.

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