Skip to main content
Glama
Sign In

Argorant

by com.argorant
OverviewDiscussionsAdmin

Send people to a connected sending tool

argorant_push_to_integration

Send the people of one of the user's Argorant campaigns, or the rows of one of their exports, into a campaign in a connected sending tool. Use it when the user sends from another tool; to send from Argorant itself use argorant_launch_campaign. The target campaign comes from argorant_list_integrations. People who bounced, unsubscribed or are blocked are never sent. To send a saved list, export it first with argorant_export_list, which uses credits as usual and needs the user's yes, and send that export; the send waits until the export is ready. The campaign in the other tool is not started and no email is sent. It is free from the Pro plan. Tell the user which campaign or export goes where and how many people that is, and send only after their explicit yes (confirmed=true). Then report the result with argorant_integration_push_status. More in the docs at https://docs.argorant.com/docs/agents/tools#send-to-other-tools and https://docs.argorant.com/docs/guides/send-to-other-tools

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": {
      "integration_id": "<integration_id>",
      "source": "<source>",
      "target_campaign_id": "<target_campaign_id>"
    },
    "name": "argorant_push_to_integration"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYescampaign sends the people of an Argorant campaign (campaign_id), export sends the rows of an export (export_id).
resultsNoExports only: which email results to send. Default valid.
confirmedNotrue only after the user's explicit yes to this send
export_idNoSource export: the export id
campaign_idNoSource campaign: the Argorant campaign id
integration_idYesThe connected tool, from argorant_list_integrations
only_not_contactedNoCampaigns only: send only people who were not emailed yet
target_campaign_idYesThe campaign inside the connected tool

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses that bounced/unsubscribed/blocked people are excluded, that the target campaign is not started and no email is sent, that the send waits on export readiness, that exporting consumes credits and needs consent, and that the operation is free on Pro. These are exactly the operational facts an agent needs before calling a cross-system mutation.

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 action, then alternatives, then safety constraints and confirmation. Most sentences carry real information, though the two documentation URLs at the end are somewhat redundant with the in-description guidance.

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 an 8-parameter cross-tool mutation with an output schema available, the description covers routing, prerequisites, exclusions, side effects, cost, and follow-up status reporting. Nothing an agent needs to call it correctly is missing.

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 schema already documents every parameter including the source enum, confirmed, and where integration_id comes from. The description reinforces the confirmed=true consent contract and the campaign/export source distinction but adds little syntax or format detail beyond what is already structured. Baseline 3 applies.

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 — sending people from a campaign or export into a campaign in a connected sending tool — and explicitly contrasts itself with argorant_launch_campaign. An agent can distinguish it from siblings 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?

Explicit when-to-use (user sends from another tool), when-not (send from Argorant itself via argorant_launch_campaign), and prerequisite routing (target campaign from argorant_list_integrations, saved lists via argorant_export_list first). It also mandates the confirmation step and names argorant_integration_push_status for reporting the outcome.

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

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