Argorant

Read the blocklist

argorant_blocklist

Read-onlyIdempotent

List the email addresses and domains this workspace never contacts, newest first, 50 per page (up to 1,000), with total and counts. Use it to check whether someone is blocked, to find entry ids for argorant_unblock, or with job_id to follow a large block from argorant_block. search finds entries containing a text, type keeps only addresses or only domains, level picks blocks for the whole workspace or for some campaigns, and campaign_id shows what applies to one campaign. Rows are short; detail="full" adds each entry's id and reason. Page with cursor=next_cursor. More in the docs at https://docs.argorant.com/docs/agents/tools#analytics-mailbox-settings-blocklist

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": "argorant_blocklist"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	Only addresses or only domains.
`level`	No	all (default), only blocks for the whole workspace, or only blocks for some campaigns.	all
`limit`	No	Entries per page, 1 to 1,000 (default 50).
`cursor`	No	next_cursor from the previous page.
`detail`	No	compact (default) or full, which adds id and reason.	compact
`job_id`	No	The job_id of a large block, to see its progress instead of the list.
`search`	No	Only entries whose value or reason contains this text.
`campaign_id`	No	What applies to this campaign, its own blocks plus the workspace-wide ones (only its own with level campaign).

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value the annotations cannot: newest-first ordering, 50-per-page default capped at 1,000, returned total and counts, cursor paging via next_cursor, and the job_id mode that returns progress instead of a list. It stops short of describing edge cases such as empty results or how long a job_id remains valid.

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?

Front-loads the core behavior and pagination, then groups the filter semantics, then paging and detail, ending with a docs pointer for edge cases. Dense but every sentence carries information an agent needs to choose parameters or page correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, when-to-use, sibling handoffs, filtering semantics and pagination for an 8-parameter read tool. An output schema exists, so return-shape explanation is not required; the description still flags total/counts and the detail=full id/reason difference, which is more than enough.

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 100%, so the structured baseline is already a 3, and the description goes beyond it by explaining relationships between parameters: job_id switches the response to progress rather than the list, and campaign_id inherits workspace-wide blocks unless level=campaign. Only detail is largely restated from the schema.

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 ('List the email addresses and domains this workspace never contacts') plus ordering and page size, which distinguishes it clearly from argorant_block (write) and argorant_unblock (the removal sibling it names). An agent can identify it 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit use cases: checking whether someone is blocked, finding entry ids for argorant_unblock, and pairing with job_id to follow a large block from argorant_block. It also spells out what each filter does (search, type, level, campaign_id), including the interaction that campaign_id covers own plus workspace-wide blocks unless level=campaign.

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

All Argorant 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.