Remove a saved place
remove_placeDeletes a saved place by name from your Snapp locations. Use it to clear out stored addresses you no longer need.
Instructions
Deletes a saved place by name.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
remove_placeDeletes a saved place by name from your Snapp locations. Use it to clear out stored addresses you no longer need.
Deletes a saved place by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint=true annotation already tells the agent this removes data, so the description's 'Deletes' adds no new safety information. It omits the behaviors that actually matter for a destructive call: whether deletion is reversible, what happens if the name does not match anything, and whether ambiguity or exact-match rules apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the action front-loaded and no filler. It is efficient, though its brevity reflects missing content rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter mutation with no output schema and zero schema description coverage, the definition should explain failure modes and result behavior. As written, the agent knows what the tool nominally does but not how to invoke it safely or what to expect on error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the single 'name' parameter has no documentation beyond its type. The phrase 'by name' weakly links the param to a place name, but nothing states whether matching is exact, case-sensitive, or how duplicate or partial names are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Deletes') and resource ('a saved place') and adds the lookup key ('by name'), so an agent can distinguish it from list_places or save_place at a glance. It stops short of an explicit contrast with the sibling save_place, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus alternatives, no prerequisite that the place must already be saved, and no note that save_place is the inverse operation for re-adding. The agent must infer all selection logic from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.