Argorant

Personalization progress and the next contacts

argorant_campaign_personalization_status

Read-onlyIdempotent

Show how many of a campaign's personal lines are written and hand out the next contacts still on the fallback, with the facts a line is written from. Use it to get work for argorant_set_lead_custom_fields and to check progress; to change the setup use argorant_set_campaign_personalization. The default answer is a compact page under max_bytes, with each contact's lead_id, title, company, place, domain, industry and a short company text, and the setup's rules on your first answer only. Write the line now from what is there; when the company text is thin or not there yet and the rest says too little, keep the fallback instead of waiting. Pass cursor=next_cursor for the next contacts. Contacts that already have a line are never listed. When several assistants write the same campaign, each passes claim_minutes (up to 60) and keeps the claim_id of its first answer, so each gets contacts nobody else holds. A company text about a different company is left out (description_status withheld), and a brand's shared text is marked so you write about the brand or the contact's own location, never another branch's town. detail=true gives the full setup and every field, view=ids only ids, as_file=true a CSV text, and list=kept_fallback the contacts kept on the fallback on purpose. More in the docs at https://docs.argorant.com/docs/agents/tools#campaigns

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": {
      "campaign_id": "<campaign_id>"
    },
    "name": "argorant_campaign_personalization_status"
  }
}

Input Schema

Name	Required	Description
`list`	No	pending (the default) lists the contacts still to write, kept_fallback the contacts kept on the fallback on purpose.
`view`	No	full (default) or ids: only lead_id plus the fields asked for, no setup or samples.
`cursor`	No	next_cursor from the answer before.
`detail`	No	true gives the full answer: the whole setup (template, limits, sample lines) and every field of each contact. It is off by default, which gives a compact page with what a line is written from.
`fields`	No	Comma-separated fields per contact, for example domain,description,keywords. The contact's fields are email, first_name, last_name, title, company, company_normalized, website, industry, city, state and country; the company's are domain, description, description_status, description_quality, description_covers, location_line, industry, category, keywords, city, state and employees.
`as_file`	No	true gives the contacts and their facts as one CSV text (file.text) instead of a list.
`compact`	No	On by default, it leaves out repeated values, keeps descriptions short and shows the setup only on the first page. false gives everything in full.
`claim_id`	No	claim_id from your first answer.
`max_bytes`	No	Size budget of the answer: 12,000 by default for the compact page and 60,000 with detail=true (250,000 for either with include_facts false).
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.
`claim_minutes`	No	Hold the contacts of this answer for you for this many minutes, so assistants working side by side get different contacts. 0 (default) holds nothing.
`include_facts`	No	true (the default) adds the company facts for each contact; false gives a much smaller answer.
`pending_limit`	No	How many contacts to hand out, up to 5,000 (default 25).
`pending_offset`	No	The older way to page. Prefer cursor.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already guarantee a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint false), yet the description still adds substantial behavior: contacts already written are never listed, description_status may be withheld when the company text mismatches, brand-level text is flagged so you do not write another branch's town, and multi-assistant coordination happens via claim_minutes/claim_id. That is real coordination and data-quality context that annotations cannot express.

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?

Front-loaded with the core action and the sibling routing before any detail, with no filler sentences. It is dense and slightly run-on in the multi-assistant and withheld-text sentences, and the final enumeration of detail/view/as_file/list duplicates schema text that did not need repeating.

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?

For a 14-parameter tool with an output schema and read-only annotations, the description supplies everything an agent needs to sequence the call: pagination via cursor, claim coordination, compact-vs-detail tradeoff, and the write-or-keep-fallback decision. Remaining parameter details are fully covered by the schema, so nothing critical is missing.

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 baseline is 3; the description earns above that by explaining the intent behind claim_minutes plus claim_id (each assistant keeps contacts nobody else holds) and by clarifying that the setup rules appear only on the first answer. The closing sentence largely restates detail/view/as_file/list from the schema, and it never mentions include_facts, pending_limit or pending_offset, which relies on the schema's own 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 opening sentence names a concrete verb pair (show progress, hand out next contacts) and the exact resource (a campaign's personalization work queue, contacts still on the fallback). It explicitly separates itself from argorant_set_campaign_personalization and positions itself as the feeder for argorant_set_lead_custom_fields, so an agent can pick it over siblings without opening a 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?

It states when to use it ('get work for argorant_set_lead_custom_fields', 'check progress'), when to use something else ('to change the setup use argorant_set_campaign_personalization'), and even gives a decision rule for the edge case where the company text is thin ('keep the fallback instead of waiting'). Both alternatives are named by tool name.

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.