Scribe Mail

Send feedback to the Scribe team

send_feedback

Send a bug report, missing-capability request, or question straight to the Scribe team. When a tool fails unexpectedly, a capability the user needs is missing, or the docs can't answer their question, OFFER the user to report it — and only send after they agree (the report includes their workspace identity). Works with any valid API key, no extra scope. Returns { received: true } once accepted; the team reads every report.

Input Schema

TableJSON Schema

Name	Required	Description
`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."
`message`	Yes	The feedback itself (max 5000 chars). Include what was attempted, what happened, and what was expected — enough for the team to act without this conversation.
`category`	Yes	bug: a tool errored or behaved wrong. missing_capability: the user needed something the API/MCP can't do. question: unanswered product question. other: anything else.
`reporter`	No	Who is reporting (e.g. the user's email), ONLY if the user agreed to share it.
`tool_name`	No	The MCP tool or API endpoint the feedback is about, when applicable.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare a non-read-only, non-idempotent, open-world write, and the description adds substantial context beyond them: the report carries the workspace identity, consent is mandatory before sending, no extra auth scope is needed, and it returns {received: true}. That is exactly the extra behavioral detail annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with purpose, then usage/consent, then operational facts. Every sentence earns its place with no redundancy.

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 single write tool with a full output schema, it covers purpose, triggers, consent workflow, identity disclosure, and auth scope. The return value explanation is bonus rather than a gap, since an output schema exists.

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 all five parameters (including the sensitive context field and the enum) are already fully documented in the schema. The description adds no parameter-level syntax or format detail beyond what structured data provides, so the 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 (send) and resource (feedback) with the exact content types accepted: bug report, missing-capability request, or question. No sibling tool in the list covers this function, so an agent can identify it immediately 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 Guidelines5/5

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

Explicitly enumerates the triggering conditions (tool fails unexpectedly, capability missing, docs can't answer) and pairs them with the required consent step ('OFFER the user... only send after they agree'). This is precisely when-to-use plus a precondition, leaving nothing to inference.

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.