Skip to main content
Glama

Privacy center status

get_privacy_ops_status
Read-onlyIdempotent

The site's privacy operations: retention policy (how many days submissions, test submissions and contacts are kept; whether old rows are deleted or anonymized; the last cleanup), privacy-request intake settings (contact email, whether export/delete requests are allowed), legal document links, how many third-party vendors are documented, people whose data was deleted and can still be restored (with their purge dates — deletes stay recoverable for 14 days), and the recent privacy audit log. Names people by email: PERSONAL DATA.

Input Schema

NameRequiredDescriptionDefault
site_idYesThe site, from list_sites
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing that deletes remain recoverable for 14 days (implying restore_privacy_data) and by flagging 'Names people by email: PERSONAL DATA'. It says nothing about result size or pagination, which keeps it from a 5.

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 scope statement is front-loaded and every enumerated clause corresponds to a real returned category, so nothing is filler. It is one very long semicolon-chained sentence, which is dense but still scannable.

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?

With no output schema, the enumeration effectively serves as the return-value contract, and the PII warning plus the 14-day restore window give the agent the operational context it needs. The only missing piece is any notion of result volume or truncation for the audit log and deleted-people lists.

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 100% and both parameters (site_id, user_goal) are fully documented in the schema, so the description's silence on parameters does not lose information. Baseline 3 is appropriate; nothing here adds meaning beyond the schema.

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?

The description opens with a specific verb+resource ('The site's privacy operations') and then enumerates exactly what is returned: retention policy, intake settings, legal links, vendor counts, recoverable deletions, and the audit log. An agent can distinguish this from siblings like get_compliance_status or list_privacy_vendors because the enumerated scope makes the boundary clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the content enumeration — an agent can infer this is the overview call for a site's privacy posture — but the description never states when to prefer it over get_compliance_status, list_privacy_vendors, or the retention-cleanup tools. No exclusions or alternatives are 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