Argorant

Check a large add of people

argorant_add_campaign_leads_status

Read-onlyIdempotent

Show how far a large add, removal, return or move of people in a campaign has come. Use it with the job_id from argorant_add_campaign_leads, argorant_remove_campaign_leads, argorant_restore_campaign_leads or argorant_move_campaign_leads (a move is followed on the campaign the people leave), or without job_id for the campaign's latest jobs. queued or running means check again in about 30 seconds. done comes with a summary of where everyone went. needs_choice means nothing was added yet, so put its question to the user and call argorant_add_campaign_leads again with their grades. failed says why in its own words, and people already added stay. A job that says it starts again by itself needs no new add. 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_add_campaign_leads_status"
  }
}

Input Schema

Name	Required	Description	Default
`job_id`	No	The job_id of the add, removal, return or move. Leave it out for the campaign's latest jobs.
`campaign_id`	Yes	The campaign's id, from argorant_list_campaigns.

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 declare a safe, idempotent read, and the description adds the operational semantics those annotations cannot: the status vocabulary (queued/running, done, needs_choice, failed), the polling cadence, that nothing has been added yet under needs_choice, that already-added people survive a failure, and that self-restarting jobs need no new add.

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?

Purpose is front-loaded and every sentence carries operational content, but the middle portion is dense, comma-spliced prose that takes effort to parse. Slightly tighter formatting would improve it without losing information.

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 two-parameter polling tool with a full output schema and read-only annotations, nothing is missing: the agent knows what to pass, how often to poll, how to interpret each terminal state, and what to do next in the needs_choice branch.

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, but the description adds genuinely non-obvious meaning: which tools supply job_id, that a move must be polled against the source campaign, and that omitting job_id returns the campaign's latest jobs rather than nothing.

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: 'Show how far a large add, removal, return or move of people in a campaign has come.' It immediately distinguishes itself from the mutation siblings (argorant_add_campaign_leads, remove, restore, move) by being the progress-reporting counterpart, even though the tool name alone is ambiguous.

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?

Explicit routing: use it with the job_id returned by four named sibling tools, or omit job_id for the campaign's latest jobs, and it even clarifies that a move is tracked on the campaign people leave. It also gives polling guidance ('check again in about 30 seconds') and the exact follow-up action for needs_choice.

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.