Skip to main content
Glama
Sign In

Wishpile

by com.wishpile
OverviewDiscussionsAdmin

Remove someone from a gift list

remove_person
DestructiveIdempotent

Removes a person from the signed-in person's gift list. This can't be undone. Removing someone also deletes every gift tracked for them, and any of those gifts that came from claiming a wishlist item releases that claim (the item shows as available again). If they have gifts, nothing is removed unless delete_gifts is true; the first call says how many gifts would go.

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": {
      "person_id": "<person_id>"
    },
    "name": "remove_person"
  }
}

Input Schema

NameRequiredDescriptionDefault
person_idYes
delete_giftsNoConfirms deleting their gifts too

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description goes well beyond them: irreversible, cascading deletion of every tracked gift, and the side effect of releasing claimed wishlist items back to available. The delete_gifts gate and the count-reporting first call are exactly the operational context an agent needs before a destructive action.

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?

Four tight sentences, front-loaded with the action and its irreversibility, then the cascade, then the gating rule. No filler or restatement of the title.

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 description still covers the return behavior of the count-reporting first call and the full blast radius of the deletion, which is what an agent needs before invoking a destructive tool. Minor gaps remain around error cases (e.g. unknown person_id) and what a successful removal returns.

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 50%, with delete_gifts documented in the schema but person_id bare. The description compensates by explaining what delete_gifts actually gates (the cascade of gift deletion) and how the gated call behaves, which is meaning the schema does not carry. person_id's semantics are only implied by context.

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 and resource ('Removes a person') scoped to the signed-in person's gift list, which cleanly separates it from remove_gift (a gift) and delete_gift_list (the whole list). An agent can pick this tool without opening the schema.

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?

Gives a concrete prerequisite pattern: if the person has gifts, nothing is removed unless delete_gifts is true, and the first call reports how many gifts would go. That implies a deliberate two-step confirm flow. It does not explicitly name alternatives like update_person, but the conditions for correct invocation are clear.

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

All Wishpile toolsInspect
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