SetLatch

Log a privacy request

create_request

Log a privacy request the site received another way (an email to the business, a phone call, a letter). Unless send_verification is false, SetLatch emails the requester a link to confirm it was them. Set received_at to when it actually arrived: deadlines run from then. Requests sent through the site’s own form are already in SetLatch, so check list_requests first to avoid a duplicate. Returns the new request’s id and link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "type": "<type>",
      "jurisdiction": "<jurisdiction>",
      "email": "<email>"
    },
    "name": "create_request"
  }
}

Input Schema

Name	Required	Description
`name`	No	The requester's name, if known.
`site`	Yes	The site: its slug from list_sites (its id or exact name also work).
`type`	Yes	access, delete, correct, optout (stop sale/sharing) or portability.
`email`	Yes	The requester's email address.
`details`	No	What they asked for, in their words.
`received_at`	No	ISO 8601 date-time it arrived, with offset. Defaults to now.
`jurisdiction`	Yes	The law it falls under: gdpr, uk, ccpa, us_state, au_app, ca_pipeda, ch_fadp, nz_privacy, other (us_state = the US state privacy laws other than California; other = anywhere not listed).
`send_verification`	No	Email the requester a verification link (default true). Set false when the team will confirm identity itself; they get a confirmation of receipt instead. Opt-outs never need verification and go live at once.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-destructive, open-world), the description discloses the key side effect: a verification email goes to the requester unless send_verification is false. It also explains that deadlines run from received_at, that opt-outs skip verification, and that the call returns an id and link — none of which the structured fields convey.

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 purpose and channel scope are front-loaded in the first clause, and each subsequent sentence delivers a distinct fact (verification email, deadline anchor, duplicate avoidance, return value). Density is high with no filler, though the parenthetical channel list is slightly long relative to its informational value.

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?

With no output schema, the description covers the return value (id and link); with a non-trivial side effect it covers the verification email; and for a non-idempotent write it flags duplicate risk. Nothing needed to call it correctly is missing given the fully-described schema.

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?

With 100% schema coverage the schema already documents all eight parameters, so the baseline is 3. The description adds real meaning for received_at by tying it to deadline computation, but the other parameters (including send_verification) are only echoed from the schema rather than extended.

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?

"Log a privacy request the site received another way (an email to the business, a phone call, a letter)" names a specific verb and resource plus the channel scope that defines it. It immediately distinguishes itself from requests that arrive through the site's own form, and from the sibling read tool list_requests.

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 states when to use this tool (off-channel requests), when not to (requests via the site's own form are already in SetLatch), and names the alternative to consult first (list_requests) to avoid duplicates. Both the inclusion and exclusion conditions are explicit.

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

All SetLatch 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.

Resources

Need Help?