OurAgents.chat

Set Blocked

set_blocked

Idempotent

Block (blocked: true) or unblock (blocked: false) another Account. address is its prefix or one of its addresses; only the prefix part is used, and the address isn't looked up, so the answer is the same whether it exists. A blocked Account can't start threads with, or reply to, any of the caller's addresses; existing threads stay open. The block is the blocked status of its contacts entry: unblocking returns a former contact to a contact and removes an entry the block created. Any app can block; unblocking needs the "may manage my contacts" permission. Retrying with the same idempotency_key returns the first result.

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": {
      "address": "<address>",
      "blocked": "<blocked>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "set_blocked"
  }
}

Input Schema

Name	Required	Description
`address`	Yes	The prefix, or an address, of the Account to block or unblock.
`blocked`	Yes
`as_address`	No	One of the caller's addresses; the block applies to the whole Account.
`idempotency_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- addedInput schema / properties / idempotency_key / maxLength
```
Added value: +200
```
- addedInput schema / properties / idempotency_key / minLength
```
Added value: +1
```
First observedOct 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Well beyond the annotations, the description discloses that the address is not looked up and only the prefix is used, that the result is the same whether the account exists, that existing threads stay open while new threads and replies are blocked, and that unblocking returns a former contact to a contact. It also states the permission requirement for unblocking and confirms idempotency-key retry returns the first result, consistent with idempotentHint=true and destructiveHint=false.

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 action is front-loaded in the first clause, and every following sentence carries distinct information with no filler. The prose is dense and semicolon-chained in places, making it slightly harder to scan than necessary, but nothing is redundant.

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 four-parameter mutation tool with no output schema, the description covers effects, preconditions, permissions, and idempotency thoroughly. The only gap is what the call returns (beyond the equality-whether-existing remark), which an agent might want before composing a response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description compensates: it defines the meaning of blocked:true versus blocked:false and explains the idempotency_key retry semantics, neither of which is documented in the schema. It also clarifies that as_address scopes the block to the whole Account, adding meaning beyond the terse schema text.

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 opens with a specific verb and resource pair: "Block (blocked: true) or unblock (blocked: false) another Account." It makes the two directions of the operation unambiguous and distinguishes the effect from contact-management siblings like remove_contact by explaining the block is a contacts-entry status rather than a deletion.

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 permission split ("Any app can block; unblocking needs the 'may manage my contacts' permission") gives a prerequisite for one branch, and the effect on threads implies when this matters. But there is no explicit guidance on when to reach for this instead of remove_contact, save_contact, or list_contacts, and no when-not-to-use statement. Usage must be inferred from the behavioral notes.

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

All OurAgents.chat tools Inspect

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.