Movahedi Privacy API

Execute a privacy API plan

privacy_execute_plan

Read-onlyIdempotent

Run several read-only privacy API operations in one call, instead of many single-tool calls. Each operation names an allowlisted GET path template, parameters, and optional select, filter, sort, limit, or count_only shaping. A parameter may use $ref:: to take a value from an earlier operation's first result. Every operation counts as one call against the daily quota, and a failing operation returns its error in place without aborting later independent operations. Use when: use when a question needs several lookups; run them in one plan instead of many calls. Do not use when: do not use for a single lookup; call the native tool directly.

Input Schema

Name	Required	Description	Default
`operations`	No	Operations to run in order, at most 10. Each has id, path, params, and optional select, filter, sort, limit, count_only.

Output Schema

Name	Required	Description
`log`	No
`meta`	No
`results`	No
`corpus_version`	No	Semantic version of the movahedi.ca statutory corpus this answer was drawn from, for example v2026.12.0. Pin it when citing; when it changes, re-read the affected resources and the change log at https://movahedi.ca/changelog/.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

addedOutput schema / properties / corpus_version

Added value: +{
+  "description": "Semantic version of the movahedi.ca statutory corpus this answer was drawn from, for example v2026.12.0. Pin it when citing; when it changes, re-read the affected resources and the change log at https://movahedi.ca/changelog/.",
+  "examples": [
+    "v2026.12.0"
+  ],
+  "type": "string"
+}

AddedOct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds substantial behavior beyond them: quota accounting ('every operation counts as one call against the daily quota'), failure isolation ('a failing operation returns its error in place without aborting later independent operations'), and cross-operation data flow via $ref. These are exactly the operational traits an agent needs before composing a multi-step plan.

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 description is front-loaded with the core behavior, then chaining, then failure semantics, then usage rules — a sensible order with no filler. Minor redundancy in the 'Use when: use when...' / 'Do not use when: do not use...' phrasing costs it a point, but no sentence is wasted.

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 batching orchestrator with an output schema already present, the description covers everything an agent needs: allowlisting, operation count cap, quota cost, $ref chaining, partial-failure behavior, and when to prefer single tools. Return-value shape is correctly left to the output schema.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema does not: the $ref syntax '$ref:<operation-id>:<field>' is spelled out along with its semantics ('take a value from an earlier operation's first result'), whereas the schema only says a $ref string is allowed. It also summarizes the shaping options (select, filter, sort, limit, count_only) and the allowlisted GET path constraint, though it does not elaborate on filter operator behavior.

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 opening sentence states a specific verb and resource ('Run several read-only privacy API operations in one call') and immediately contrasts it with the alternative pattern ('instead of many single-tool calls'). An agent can distinguish this batch tool from siblings like privacy_get_enforcement_case or privacy_search_api without opening any 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?

Explicit when/when-not guidance is present: 'use when a question needs several lookups' and 'do not use for a single lookup; call the native tool directly.' This names both the selecting condition and the alternative tool class, 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 Movahedi Privacy API 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?