Skip to main content
Glama
mike-tih

icloud-mcp

by mike-tih

Contacts Delete

contacts_delete
Destructive

Delete a contact permanently from iCloud using its contact ID, as obtained from contacts_list or contacts_search.

Instructions

Delete a contact permanently.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contact_idYesContact URL/ID from contacts_list or contacts_search.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is established. The description adds the word 'permanently', which conveys irreversibility, but it does not disclose side effects, cascading deletions, or any other behavioral context beyond that.

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?

The description is a single, front-loaded sentence with no filler or redundant information. It earns its place by stating the action and permanence without unnecessary elaboration.

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 one-parameter destructive tool, the combination of description, schema, and annotations is nearly sufficient. The output schema exists, the parameter source is documented, and the destructive nature is both annotated and verbally reinforced; a small usage-guidance note would make it fully 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 100%, and the single contact_id parameter is already described as coming from contacts_list or contacts_search. The tool description itself adds no parameter-level meaning, so the schema carries the burden and justifies the baseline score.

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?

The description uses a specific verb and resource: 'Delete a contact permanently.' It clearly separates this from sibling tools like contacts_get, contacts_update, and contacts_search, and the word 'permanently' reinforces that this is the destructive delete operation.

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 description makes the tool's action obvious, but it does not explicitly state when to use it or when to avoid it. It does not mention alternatives, exclusions, or any prerequisite such as retrieving the contact_id first, though the schema partially covers that.

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