Scribe Mail

Get a visitor

get_visitor

Read-onlyIdempotent

Fetch one identified visitor (the customer's identify subject — NOT a Scribe member) by its Scribe id — the uuid from list_visitors, not the distinct_id (to look up by distinct_id, filter list_visitors instead). Returns the visitor's distinct_id, traits (PII lives here), first/last_seen_at, first_touch attribution (the signature click that drove their first visit), and stats — the visitor's lifetime engagement (event count + total value).

Input Schema

Name	Required	Description	Default
`id`	Yes	The visitor's Scribe `id` (a uuid, as returned by list_visitors) — NOT the distinct_id.
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."

Output Schema

Name	Required	Description	Default
`data`	Yes
`stats`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 28, 2026
- removedOutput schema / properties / data / properties / first_touch / properties / click_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / first_touch / properties / click_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / first_touch / properties / email_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / first_touch / properties / email_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / first_touch / properties / signature_template_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / first_touch / properties / signature_template_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / data / properties / first_touch / properties / teammate_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / data / properties / first_touch / properties / teammate_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedOct 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations by noting that traits contain PII and by explaining first_touch attribution and lifetime engagement stats. It does not discuss auth needs or rate limits, but for a read-only lookup the added disclosure is meaningful.

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 key purpose is front-loaded, and the description is compact overall. It is a single dense sentence with nested parentheticals, and some return-field detail overlaps with the output schema, but every clause still provides useful orientation rather than 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 two-parameter read-only lookup with full schema coverage, annotations, and an output schema, the description covers the necessary conceptual context: what is fetched, what identifier to use, what identifier not to use, and the main returned data categories. Nothing essential is missing for correct invocation.

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 the schema already documents both `id` and `context` in detail. The description reinforces the critical `id` versus `distinct_id` distinction, but largely repeats what the schema says and does not add further meaning for `context`. With full schema coverage, the baseline of 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: fetch one identified visitor by its Scribe `id`. It immediately distinguishes this from a Scribe member and from a distinct_id lookup, and it names `list_visitors` as the source of the id. An agent can tell exactly what this tool returns and how it differs from related list/breakdown tools.

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?

It explicitly says to use this tool for a single identified visitor by Scribe `id`, and explicitly redirects distinct_id lookups to `list_visitors` instead. The `id` source is also stated as coming from `list_visitors`, leaving little inference required.

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

All Scribe Mail 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.