Skip to main content
Glama

Report a security problem

report_security

REPORT A SECURITY VULNERABILITY — PRIVATELY. This is the channel for a real security problem in the platform itself: authentication or authorization bypasses, data exposure across accounts or shops, injection, SSRF, secret leakage, privilege escalation, or a way to move money without the agreement both sides accepted. Security reports are PRIVATE to the platform's operators: they never touch the public roadmap, related-ticket lists, partner routing, or any shared board, and other reporters never see them. DO NOT USE report_gap FOR ONE. A vulnerability is not a missing verb or a poor result, and filing it on the homework list exposes it to the wrong audience. If you are not signed in, or you are calling with a shop's agent key, this door refuses on purpose and tells you where to email instead — an unowned disclosure cannot be followed up. WHAT TO SEND. title is one line naming the class of problem. body is the report: what is wrong, the exact steps or request that reproduce it, and what an attacker could do with it. Do not paste your human's brief, credentials, or other people's personal data; redact enough to be safe and say what you redacted. surface optionally names the tool, verb or page. WHAT YOU GET BACK. A ps_… receipt — the only handle to this report. Only its SHA-256 is stored, so it cannot be recovered if lost. The report's title and body are NEVER echoed back, now or by any later call. Keep the receipt and use security_check to read the operators' messages, and security_reply to add detail. CAPS AND RETRIES. Five new reports per signed-in account per rolling 24 hours. Pass idempotency_key (up to 64 characters) on a call you might repeat: the same key returns the SAME receipt without filing twice or spending the cap again.

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": {
      "title": "<title>",
      "body": "<body>"
    },
    "name": "report_security"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesthe report: what is wrong, how to reproduce it, and the impact. Never include credentials or other people's personal data — say what you redacted
titleYesone line naming the security problem, e.g. 'another account's orders are readable by id'
surfaceNooptional: the tool, verb or page the problem is in — e.g. `checkout_intent` or `/admin`
idempotency_keyNooptional, up to 64 characters: a retry with the same key returns the SAME receipt and does not file a second report

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: reports are private to operators and never touch the roadmap or partner routing, the response is a ps_ receipt whose SHA-256 alone is stored and whose title/body are never echoed, and there is a cap of five new reports per account per rolling 24 hours. The conditional idempotency behavior (same key returns the same receipt without spending the cap) refines rather than contradicts idempotentHint=false, which describes the default call. Slightly marked down only because the return contract is not named as a schema object or given an exact shape.

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 the core action and the do-not-use sibling before any detail, and the CAPS/RETRIES block sits last where an agent needs it. It is long and partly restates the schema (what body and title should contain), and the all-caps headers occasionally read as emphasis rather than structure, but almost every sentence carries a decision-relevant fact.

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 write tool with no output schema, the definition covers the whole lifecycle an agent needs: what qualifies, what to include and redact, what is returned (a non-recoverable ps_ receipt), how to follow up (security_check, security_reply), rate limits, and retry safety. Nothing material to a correct call is left unstated.

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 baseline is 3, but the description adds real guidance on top: title should name the class of problem, body must carry reproduction steps and impact plus a redaction statement, surface is optional naming of tool/verb/page, and idempotency_key is tied to a concrete retry consequence (same receipt, no second filing, no cap spend). The body-content constraints (no credentials, no third-party personal data) go beyond the schema text.

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 and resource ('report a security vulnerability') and immediately bounds the domain with concrete examples: auth bypass, cross-account data exposure, injection, SSRF, privilege escalation, unauthorized money movement. It explicitly names the sibling it is not (report_gap), so an agent can route without opening either 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?

Gives explicit when-to-use (real platform vulnerabilities), when-not-to-use (a missing verb or poor result belongs in report_gap, with the stated reason that the homework list exposes it to the wrong audience), and prerequisites (must be signed in; shop agent keys are refused and redirected to email). Alternatives and exclusions are both named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources