Scribe Mail

Analytics — signature views

get_analytics_views

Read-onlyIdempotent

Signature-view counts over a date range. By DEFAULT a timeseries bucketed by granularity (hour/day/week/month, UTC): { data:[{period, count}], totals:{count} }. Set group_by (signature_template | marketing_campaign | teammate | country) for a ranked breakdown instead: { data:[{id, label, view_count, click_count, clickthrough_rate}], pagination } — each breakdown row already carries views, clicks, AND the clickthrough rate, so one call answers "which signature/teammate drives the most engagement". Filter by start_date/end_date and any of signature_template_id, marketing_campaign_id, teammate_id.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	1-based page (breakdown only; ignored for the timeseries).
`limit`	No	Page size 1–100 (breakdown only; default 20).
`order`	No	Sort direction. Default desc.
`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."
`end_date`	No	Range end (inclusive), ISO-8601 date YYYY-MM-DD. Default: today.
`group_by`	No	If set, return a ranked breakdown by this dimension instead of a timeseries: signature_template \| marketing_campaign \| teammate \| anchor (link) \| country.
`start_date`	No	Range start (inclusive), ISO-8601 date YYYY-MM-DD. Default: 2 months ago.
`granularity`	No	Timeseries bucket size: hour \| day \| week \| month (default day). Ignored when `group_by` is set. `hour` is capped at a 31-day range.
`teammate_id`	No	Restrict to one teammate (their UUID).
`marketing_campaign_id`	No	Restrict to one marketing campaign (its UUID).
`signature_template_id`	No	Restrict to one signature template (its UUID).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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 carry readOnly/idempotent/non-destructive, so the safety burden is covered. The description adds real behavioral context: the default mode and shape, UTC bucketing, the hour-granularity 31-day cap, and that breakdown rows include clicks and CTR. It could note rate limits or large-range behavior, but this is strong added value beyond annotations.

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-loaded with purpose and default behavior, then the alternative mode, then filters. It is dense and somewhat long, but nearly every clause carries invocation-relevant meaning; the return-shape sketches are arguably redundant given the output schema exists.

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 an 11-parameter analytics tool with an output schema, it covers mode selection, defaults, filters, bucketing constraints, and the response shapes of both modes, leaving no gap an agent would need to guess at before calling.

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 the baseline is 3. The description goes beyond it by explaining the semantic split (group_by switches the response shape entirely, page/limit apply only to breakdown) and by enumerating group_by dimensions and filter semantics, which materially aids correct invocation.

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+resource ('Signature-view counts') with explicit scope (date range), and differentiates itself from siblings like get_analytics_clicks and list_analytics_events by naming the entity counted. An agent can distinguish it without opening the 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?

Clearly explains the two modes and when each applies: default timeseries, or set `group_by` for a ranked breakdown. It even gives a motivating question ('which signature/teammate drives the most engagement'). It stops short of naming competing analytics siblings explicitly, so no exclusion guidance, but context is clear.

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.