Capable

Review and erase private LinkedIn data

manage_linkedin_privacy

Destructive

Owner-only LinkedIn review/erasure; no provider/sign-in changes. begin subject_context needs exact verified provider identity: covers all messages in its local conversations plus additional_message_ids. connection_review exports but cannot erase. Returns expiring owner download/counts/limits, no bodies. Human-review third-party data, other references and shared notes before disclosure/deletion: not semantic search or ready-to-send disclosure. status checks freshness. prepare_erasure(reviewed:true) selects exact IDs (max5000) and optional participant metadata. Show counts and ongoing suppression before explicit approval and commit_erasure(receipt,confirm:true); replay is idempotent. Changed/expired scope needs new review. Erasure fences reimport; metadata erasure suppresses future metadata. Unrelated history, shared notes and provider copies are separate. Never infer identity/consent from text.

When to use: Review a verified person's imported data rights request.

Example: Review this person's LinkedIn data.

Input Schema

Name	Required	Description
`scope`	No	One of: subject_context \| connection_review.
`action`	Yes	One of: begin \| status \| prepare_erasure \| commit_erasure.
`case_id`	No	For status/prepare_erasure: the unexpired case returned by begin.
`confirm`	No	For commit_erasure: true only after explicit confirmation of the plan, including ongoing metadata suppression if chosen.
`receipt`	No	For commit_erasure: the ten-minute erasure receipt returned by prepare_erasure.
`reviewed`	No	For prepare_erasure: true after reviewing the download, identity, exact message selection and third-party data.
`message_ids`	No	For prepare_erasure: exactly the reviewed local message ids to erase; empty only for metadata-only erasure.
`connection_id`	No	For begin: your own LinkedIn connection id.
`subject_identity`	No	Must not be empty.
`identity_verified`	No	For subject_context: true only after verifying the person's exact provider identity.
`additional_message_ids`	No	For subject_context: additional reviewed local messages in this connection referring to the person elsewhere.
`erase_participant_metadata`	No	Boolean (true/false).

Output Schema

Name	Required	Description	Default
`case`	No
`note`	No
`plan`	No
`outcome`	No
`download_url`	No
`review_conflict`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

removedInput schema / properties / erase_participant_metadata / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / erase_participant_metadata / type
```
Added value: +[
+  "boolean",
+  "string",
+  "number"
+]
```

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```

Changed5 schema fields changedOct 20, 2026

removedInput schema / properties / additional_message_ids / items / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

removedInput schema / properties / case_id / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

removedInput schema / properties / connection_id / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

removedInput schema / properties / message_ids / items / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

removedInput schema / properties / receipt / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changed10 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / case / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / case / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / outcome / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / outcome / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / plan / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / plan / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / review_conflict / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / review_conflict / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
AddedOct 17, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and non-read-only, yet the description adds substantive behavior: expiring owner downloads and ten-minute receipts, counts/limits with no message bodies, max 5000 IDs, erasure fencing future reimports, metadata suppression, and explicit non-coverage (provider copies, shared notes, unrelated history). The 'replay is idempotent' statement is scoped to commit_erasure and sits alongside other non-idempotent actions, so it qualifies rather than contradicts idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening clause is well front-loaded ('Owner-only...; no provider/sign-in changes') and 'When to use' plus the example are cleanly separated. However, the body is a dense run-on of semicolon-joined fragments covering actions, scopes, limits and caveats in one block, which forces re-reading and would benefit from per-action structure.

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 12-parameter, four-action destructive tool with an output schema, the description covers the full lifecycle: prerequisites, verification gates, review-before-erasure requirement, explicit confirmation, idempotent replay, and scope expiry. It also states what is not erased, which is exactly the residual risk an agent needs.

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?

With 100% schema coverage, the baseline is 3, but the description adds meaning the schema does not: cross-parameter coupling (subject_context needs verified provider identity and covers local conversations plus additional_message_ids; commit_erasure needs both receipt and confirm), the 5000 selection cap, and the empty-array-is-metadata-only rule for message_ids. It stops short of covering every parameter (e.g., connection_id, erase_participant_metadata typing).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource set (owner-only LinkedIn review/erasure) and states scope boundaries ('no provider/sign-in changes'), so an agent knows this is a data-rights review/erasure workflow rather than a messaging tool. It does not explicitly name a sibling tool as the alternative, and 'connection_review' is a scope value rather than a routing target, so sibling differentiation is implicit at best.

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 gives a clear trigger ('Review a verified person's imported data rights request') and an explicit action order (begin -> status -> prepare_erasure -> commit_erasure), plus a routing hint that connection_review exports but cannot erase. It never states when NOT to use this tool or names a concrete alternative tool for the export-only path, so the exclusion side is incomplete.

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

All Capable 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?