Skip to main content
Glama

Open one message in full

get_message
Read-onlyIdempotent

Use when the owner wants to reply to, call or deliver to one visitor: returns one message, order, booking, sign-up or quote request (id from get_messages) with the visitor's full contact details. They are the visitor's personal data, for the site's owner.

Input Schema

NameRequiredDescriptionDefault
site_idYesThe site id: the first part of the site URL, e.g. "bella-roma" for https://bella-roma.ginta.page (see list_sites).
message_idYesThe message's id from get_messages.

Output Schema

NameRequiredDescriptionDefault
textYesThe answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).
messageYesThe message in full.
site_idYesThe site id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / text
      Added value: +{
      +  "description": "The answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "site_id",
      -  "message"
      -]New value: +[
      +  "site_id",
      +  "message",
      +  "text"
      +]
  2. Added

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, non-destructive and closed-world behavior. The description adds important context beyond annotations: the returned record contains the visitor's personal data, intended for the site's owner. It does not mention auth requirements explicitly, but the owner framing covers the access scope.

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 description is a single, front-loaded sentence that begins with the usage condition and then covers return content and privacy. It is slightly long but every clause contributes useful information; no filler words.

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?

Given the low complexity, 100% schema coverage, existing output schema, and rich annotations, the description provides sufficient context: when to use, what is returned, and the personal-data sensitivity. Minor gaps like error behavior are reasonable to omit.

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%, so both site_id and message_id are already documented in the schema. The description reinforces that message_id comes from get_messages, but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

The description states a specific verb and resource: 'returns one message, order, booking, sign-up or quote request' with 'the visitor's full contact details'. It also distinguishes itself from the sibling get_messages by naming it as the source of the id.

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?

It gives a clear when-to-use condition: 'Use when the owner wants to reply to, call or deliver to one visitor.' This implies a retrieval-then-contact workflow. It does not explicitly state when not to use it or name alternatives beyond the id source, but the context is largely clear.

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