Ignaru for agents

Everything an agent needs to work in Ignaru quickly and safely. The same text is at /llms-full.txt, in the MCP prompt quickstart, and in ignaru help agents. Setup for each client is in CLI and MCP.

Ignaru runs a team's outbound growth as loops (the app also says workspaces): boards of steps that find leads, enrich and research them, draft outreach, wait for a human Approve, handle replies and book calls. You reach it three ways, all acting as one person with their own key:

• MCP: https://ignaru.com/api/mcp/mcp (Streamable HTTP), header Authorization: Bearer ig_pk_…
• CLI: ignaru (add --json to any command for machine output)
• REST: https://ignaru.com/api/v1 with the same header

First call

MCP context · CLI ignaru context --json · REST GET /api/v1/context

One answer with your team, your role, what your key may do, the credit balance and this week's spend, rate limits and batch sizes, and where work is waiting (drafts to approve, replies not handled, upcoming calls), plus every loop with its id.

Rules that never change

• Nothing reaches a person outside the team until an Admin presses Approve in the Ignaru app. No key, CLI or MCP call can approve or send. Draft freely; say "it's waiting for your Approve in the app".
• Keys act as Operator at most: they build loops, add and edit leads, and write drafts.
• Inviting teammates emails real people. Show the user the list, get a yes, then send with confirm: true (CLI: --yes). Without it nothing is sent.

Saving calls

• Name things instead of looking up ids. Loops by exact name, leads by email or exact name, steps by title or by kind when only one step has it. get_loop {"loopId":"UK fintech founders"}, connect_steps {"loopId":"…","from":"linkedin","to":"approve"}.
• get_loop describes a loop in one call: steps in order, pipes, leads by stage, drafts waiting, spend, and why it can't go live.
• create_loop builds a whole board: {"name":"Warm replies to calls","steps":["replies","booking","approve","call"]}. A step that writes to people (coldemail, followup, linkedin, booking…) feeds an approve step: its drafts wait there for an Admin.
• add_leads takes 200 at a time and merges by email (the answer counts added and merged). dryRun: true previews.
• enrich_leads takes 25 leads by id, email or name; dryRun: true gives the credit estimate first.
• search_leads answers with total, the team's count per stage (byStage) and nextCursor for the next page.
• Every write takes an optional idempotencyKey (8 to 128 of A-Z a-z 0-9 _ . : -): retrying with the same key returns the first answer instead of writing twice.

When something fails

Errors carry a code, a message, a Fix (what to call next) and, where it helps, Valid (the values that would have worked: step ids, stages, loop names). Over REST they are JSON: {"ok":false,"code","message","hint","valid"}. 429 means wait the seconds it says. server_error is Ignaru's fault, not yours: retry once, then tell the user.

Common jobs

Ignaru has no people search: give add_leads the people you have, or set up a Find step (signals, list) on a loop.