Skip to main content
Glama

Unpin doc

unpin
Destructive

Stop new chats reading a pin, when a round changes direction. Take pin_id and space_id from list_space; a pin held by a parent space comes off that space and everything under it. The doc itself stays, with the same access.

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": {
      "pin_id": "<pin_id>",
      "space_id": "<space_id>"
    },
    "name": "unpin"
  }
}

Input Schema

NameRequiredDescriptionDefault
pin_idYes
space_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the destructiveHint annotation, the description explains that a parent-space pin is removed from that space and everything under it, while the doc itself remains with the same access. This usefully clarifies what is destroyed and what is preserved.

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 compact and front-loads the effect before giving parameter sourcing and cascade behavior. The phrase 'when a round changes direction' is domain jargon, but it does not add significant bloat.

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 simple destructive mutation with two required parameters, it covers the key behavior: cascade removal, doc persistence, and parameter sourcing. It could be stronger by naming the pin sibling explicitly and saying more about permissions or response, but it is largely complete.

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 description coverage is 0%, so the schema does not explain the two UUID parameters. The description compensates by saying to take pin_id and space_id from list_space and implies the space context for the pin, but it does not fully define each parameter's role.

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 states a specific effect: stopping new chats from reading a pin. It is clear that this removes a pin association rather than deleting the doc, though it does not explicitly contrast with the sibling pin tool.

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?

It gives an implied use case ('when a round changes direction') and tells the agent where to source the IDs from list_space. However, it does not explicitly say when to use this versus pin, or when not to use it.

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