Skip to main content
Glama
Sign In
linkedin-mcp

linkedin-mcp

by amankumar-2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Delete a LinkedIn post

delete_post
DestructiveIdempotent

Permanently deletes a signed-in member's LinkedIn post by URN (share or ugcPost); this action cannot be undone.

Instructions

Permanently deletes one of the signed-in member's posts by URN (urn:li:share:… or urn:li:ugcPost:…). This cannot be undone.

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": {
      "post_urn": "<post_urn>"
    },
    "name": "delete_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
post_urnYesThe post URN returned when the post was created.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so 'cannot be undone' largely restates structured data; the genuinely additive behavior is the ownership restriction to the signed-in member's posts. Nothing is said about what happens on a non-owned or malformed URN, or what the call returns on success versus failure.

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

Conciseness5/5

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

Two short sentences with no filler: the destructive action and ownership scope come first, the irreversibility warning second. Every clause carries information an agent needs before calling.

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 single-parameter destructive tool whose safety profile is fully covered by annotations and whose only parameter is fully documented, this is close to complete. The remaining gap is error/edge behavior — what happens with a URN the member does not own or one that no longer exists.

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 the baseline is 3, but the description earns an extra point by naming the concrete URN forms (urn:li:share:… and urn:li:ugcPost:…) and tying them to post creation, meaning beyond the schema's generic 'post URN' line.

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 plus resource ('Permanently deletes ... posts by URN') and narrows scope to 'the signed-in member's' own posts, which cleanly separates it from the create_* siblings. The two accepted URN prefixes are named, so an agent knows exactly what identifier class is valid.

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?

The ownership constraint ('one of the signed-in member's posts') implicitly tells the agent when this tool is applicable and when it is not, but there is no explicit when/when-not framing and no mention of prerequisites such as a valid authenticated session. Usage is inferable rather than stated.

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

Deploy Server

Other Tools