Skip to main content
Glama
Sign In

Widely

by com.widely-mobile
OverviewDiscussionsAdmin

Unblock a contact

unblock_contact
DestructiveIdempotent

Removes a block when the user asks you to unblock a person, a number, or a saved contact. Pass block_id from list_blocked_contacts, or phone_number, or contact_id. The block is removed for this Widely user, on every number they use. Unblocking someone who is not blocked leaves the list as it is.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "unblock_contact"
  }
}

Input Schema

NameRequiredDescriptionDefault
block_idNoBlock id from list_blocked_contacts.
contact_idNoSaved contact id. Removes blocks for that contact's Widely user and saved numbers.
phone_numberNoPhone number to unblock.

Output Schema

NameRequiredDescriptionDefault
statusYesunblocked when this call removed a block. not_blocked when nothing on the list matched.
removedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description adds real substance: the removal propagates to every number associated with the user's Widely identity, which is broader than a single-number block. It also confirms the idempotent no-op outcome rather than leaving the agent to infer it. Permission or failure behavior is not covered, keeping it below a 5.

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 short sentences, front-loaded with purpose, then identifiers, then scope, then edge case. No filler, no repetition of the title, and the no-op note is placed last where it belongs.

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?

An output schema exists, so return values need no explanation, and all three parameters are documented. The remaining gap is that it never states that one of the three identifiers is mandatory or what happens if none is supplied on this destructive mutation.

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%, so the baseline is 3. The description does add one genuinely useful fact the schema cannot express: the three parameters are alternatives ('Pass block_id ... or phone_number, or contact_id') despite zero required parameters, implying at least one must be supplied. That is helpful but limited to a single sentence.

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 block') plus the trigger condition and the three identifier types it accepts. The scope statement ('for this Widely user, on every number they use') makes the effect unambiguous and clearly the inverse of block_contact in the sibling set.

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 clear activation condition ('when the user asks you to unblock') and routes block_id collection to list_blocked_contacts. It also covers the no-op case ('Unblocking someone who is not blocked leaves the list as it is'), which pre-empts a common confusion, but it never explicitly contrasts with block_contact or says which identifier to prefer when several are available.

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

All Widely 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