sebbi.pro - the proof layer for AI

Challenge an automated decision (Ask Why)

sebbi_ask_why

For a person who was turned down by a computer (credit, a job, insurance, an account, benefits, housing). Writes their legal request under UK GDPR Articles 22A-22D and 15 or EU GDPR Articles 22 and 15 (and AI Act Article 86 where it applies), seals it with a timestamp so the one-month deadline is provable, and returns the letter, where to send it, a private tracking link and a reply link the organisation answers through. Give the person the letter and the tracking link, and tell them to keep the tracking link private. Use only the person's real details; ask for what you don't know. Personal details are not stored: only the letter's fingerprint.

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": {
      "company": "<company>",
      "what_happened": "<what_happened>",
      "your_name": "<your_name>"
    },
    "name": "sebbi_ask_why"
  }
}

Input Schema

Name	Required	Description
`company`	Yes
`your_name`	Yes
`account_ref`	No
`jurisdiction`	No
`your_contact`	No
`decision_date`	No	YYYY-MM-DD, roughly
`decision_type`	No
`what_happened`	Yes
`company_domain`	No
`representations`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only flag write/open-world/non-destructive; the description adds the substantive behaviour: the letter is timestamped to prove the one-month deadline, jurisdiction determines which statute the letter cites (UK GDPR 22A-22D and 15, EU GDPR 22 and 15, AI Act 86), and personal details are not stored, only the letter's fingerprint. That privacy and deadline-provenance disclosure is exactly the context an agent needs before submitting someone's personal data.

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?

One dense paragraph where nearly every clause carries information (audience, legal basis, output artifacts, handling instructions, privacy note). It is front-loaded with the audience and action, though the agent-facing instructions are buried mid-sentence rather than separated out.

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?

For a 10-parameter, write-style tool with no output schema, the description still tells the agent what comes back (letter, destination, tracking link, reply link) and how to hand it over, plus the no-storage privacy guarantee. The remaining gap is the unglossed auxiliary parameters, which the description never compensates for.

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 coverage is 10% across 10 parameters, so the description carries most of the burden. It does explain what drives `jurisdiction` (UK vs EU statute choice) and effectively enumerates `decision_type` values, plus a rule for missing data, but `account_ref`, `company_domain`, `representations`, `your_contact` and the distinction between `company` and `company_domain` are untouched by both schema and description.

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 concrete verb and artifact: it drafts and seals a GDPR Article 22/15 access-and-explanation request, then returns the letter, the address to send it to, a tracking link and a reply link. The opening clause ('a person who was turned down by a computer') fixes the exact trigger, and none of the sibling tools (billing, notarize, verify_chain) overlap with this purpose.

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 clearly names the qualifying situation and the enumerated decision types (credit, job, insurance, account, benefits, housing), and gives post-call instructions: hand over the letter and tracking link, keep the tracking link private, use only real details and ask for unknowns. It stops short of saying when not to use it or what to do if the decision wasn't automated, so a 4 rather than a 5.

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

All sebbi.pro - the proof layer for AI 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?