Ninjo

Delete a contact limit by id. Returns { success: true }.

delete_contact_limit

Delete a creator resource (removes the S3 object and the DB row). Returns { deleted, resource_id }.

delete_creator_resource

Delete a custom notification by id. Returns { success: true }.

delete_custom_notification

Delete a custom property by id. Returns { success: true }.

delete_custom_property

Delete a context document from a Ninjo agent. If the document has an S3 file_key, deletes it from S3 as well. Returns { success: true }.

delete_document

Delete a notification destination by id. Returns { success: true }.

delete_notification_destination

Delete a property action by id. Its subtype row (http / crm_*) is removed too. Returns { success: true }.

delete_property_action

Delete a Cortex thread and all its messages.

delete_thread

Delete a trigger by ID and type. type must be one of: keywords, all-messages, comments, ads, outgoing-messages, instagram-story. Cascades to trigger_negative_config if present. Returns { success: true }.

delete_trigger

Remove the negative config from a trigger. The trigger itself is not affected.

delete_trigger_negative_config

Delete a WhatsApp template definition by id (via mk1-chat). Refused with 409 if any notification destination still references it (detach or delete those first) — the definition is never silently orphaned. Returns { ok, influencerId, id }.

delete_whatsapp_template_definition

Delete a workflow by id. Returns { success: true }.

delete_workflow

Deploy the Cortex SDK (system.md + the 8 v5Config fields) to a Ninjo agent in one correct-by-construction call. Bakes the multi-step deploy the cortex skills enforce but the raw tools don't: (1) update the prompt column if `system` changed, (2) merge changed v5Config fields, (3) re-sync trigger_keywords whenever `keywords` is provided — so keyword changes are always dual-written (v5Config context AND what actually fires) and `system` never lands in v5Config. Diffs each provided field against the live config and only calls what changed; omitted fields are left untouched (PATCH semantics — there is no set-to-null). Then re-fetches and verifies (version bumped, fields match, no v5Config↔trigger_keywords drift). On verified=false or partial=true the deploy did NOT fully succeed: pass rollback_version_id to restore_prompt_version to revert both prompt and config. Returns the deploy report. IMPORTANT: this ships the agent's MESSAGES only (prompt + v5Config). It does NOT create the contact limits, custom notifications, or follow-up workflows that turn a prompt into a working agent — build those separately (upsert_contact_limit / upsert_custom_notification / upsert_workflow), gated on your custom properties. verified=true means the messages are live, not that the system is complete. The result also carries a `completeness` report (the same deterministic build/wiring audit as diagnose_agent mode=quick) run AFTER the deploy — resolve its critical/warn findings (or run scaffold_agent_activation) before treating the agent as done.

deploy_agent_sdk

Audit a live agent and return ranked defects, each with the exact fix tool. An agent is a SYSTEM, not a prompt: this is the "definition of done" as code. mode="quick" (default) — DETERMINISTIC tier only. Free, fast, reproducible: run it after every iterate. Service-role checks: no terminal contact limit, an active agent not linked to a connected account, ungated follow-ups, string-typed gating properties, hand-made properties duplicating an auto one (e.g. agendo_llamada ↔ call_booked), inert properties, missing conversion notification, robotic cadence (humanization off), and v5Config↔trigger_keywords drift. score/complete come from this tier. mode="full" — also runs two LLM-graded tiers (costs model calls — run pre-deploy or periodically, NOT every iteration): - behavioral: samples recent low-quality conversations (bad/stuck/low-happy) and grades them server-side — filter leak, NO_RESPONSE paraphrase, reasoning leak, premature booking. Needs a JWT-scoped token. Returns the sampled transcripts too. - prompt_audit: grades the deployed SDK (system.md + v5Config) against the best-practices rubric BP-2…BP-10 (fetched live from the wiki) — contradictions, example coverage, unguarded actions, voice drift, stale CTAs. Returns { agent_id, checked_at, mode, score (0–100, deterministic), complete, findings, behavioral, prompt_audit }. Resolve every critical/warn finding (across all tiers) before treating the agent as done.

diagnose_agent

Generate synthetic conversations for an agent by invoking the replicant Lambda. Two mutually-exclusive modes: pass `personas` for AI-simulated leads (user generated by an LLM), or pass `scripted_scenarios` to replay fixed user messages with no user-side inference (only the agent responds). Fan-out across the chosen items and return conversations in both structured and markdown formats. Returns { conversations, test_run_ids, lambda_invocations, lambda_errors, conversations_fetched, conversations_filtered, elapsed_seconds, warning }. `min_turns` defaults to 1 in scripted mode and 3 with personas; `warning` is non-null when every fetched conversation was dropped by min_turns (returned 0), suggesting a lower min_turns. influencer_id is inferred from the JWT when using an influencer-scoped token — only required when using admin or API key auth.

generate_synthetic_conversations

Report whether the influencer has connected an Instagram / Facebook account, and whether any connected account's token is invalid (needs reconnection). Use this to poll after handing the owner a connect link from create_connect_link, and to check before onboarding steps that require a connected account. Returns { influencer_id, channels: { instagram?: { connected, invalid_token, name }, facebook?: {...} } }. Only requested channels are present (pass provider to narrow).

get_connection_status

Get the full configuration snapshot for a Ninjo agent: agent metadata, system prompt, and AgentConfig settings. Requires an influencer-scoped JWT. Returns { agent, config }.

get_agent_config

Fetch a windowed operational snapshot for an agent. Every section honors the `days` lookback (default 7). Sections (pass `sections` to fetch only what you need): - volume: new conversations / qualified leads / bookings sent over the window, plus a last-24h line - funnel: the influencer's configured funnel stages with conversation counts and conversion rates between consecutive stages (labelled with their own step names) - sources: per-source (Organic DM / Story Reply / Ad title) conversion performance - objections: stalled leads (funnel 1–3, quiet >72h) grouped by objection (MONEY/TRUST/TIMING/PRIORITY/UNKNOWN); null when the influencer has no objection properties configured Sections are computed independently: a slow or failing section comes back null with an entry in `warnings` — the rest of the report still arrives. `qualification.definition` states what "qualified" means in these numbers. To COMPARE several agents, prefer get_agent_metrics (one call, one row per influencer) over calling this tool per influencer. influencer_id is inferred from the JWT when using an influencer-scoped token (CUID like "cm…", not a username).

get_agent_insights

Calculate performance metrics for one or all agents. Includes volume (new_conversations, qualified_leads), engagement, funnel, lead score, booking rates, happy path, nurturing quality, monotonicity of funnel progression, and relative risk scores (z-scores). This is the tool for COMPARING agents: multi-influencer tokens that omit influencer_id (on an unscoped connection) get one row per authorized influencer in a single call — do not loop get_agent_insights per influencer. Returns { days, min_leads, agents: [{ influencer_id, influencer_username, leads, new_conversations, qualified_leads, avg_engagement_score, avg_funnel, avg_lead_score, funnel_to_lead_score_ratio, bookings_sent, booking_send_rate, call_booked_observed_leads, calls_booked, call_book_rate_total, call_book_rate_per_lead_observed, call_book_rate_per_booking_observed, pct_calls_booked_low_lead_score, avg_happy_path_score, avg_nurturing_score, pct_happy_lt_60, pct_nurture_lt_60, pct_lead_score_eq_1, pct_funnel_ge_4, premature_rate_refined, stages_compared, monotonic_violations, worst_drop, lead_score_monotonic_non_decreasing, risk_raw, risk_score_0_100 }] }.

get_agent_metrics

Fetch context data required to configure contact limits: available agents and custom properties with options. Returns { agents, customProperties }.

get_contact_limits_context

Fetch real production conversations from influencer_conversation_rollup_view_rls + messages table. Returns conversation metadata and full message history. Modes: - recent: latest conversations with ≥3 messages - booking: booking link was shared with the lead - high-funnel: funnel stage ≥ 4 - high-score: Lead Score > 3 - bad: funnel ≥ 4 but lead score ≤ 3 (high funnel, low quality) - low-happy: happy_path_score < 60 - high-happy: happy_path_score ≥ 80 - stuck: agent sent ≥ 6 messages but funnel < 3 influencer_id is inferred from the JWT when using an influencer-scoped token. Returns { influencer_id, mode, count, conversations: [{ conversation_id, contact_id, contact_username, meta: {...}, messages: [{direction, sent_at, content}] }] }. The contact_id can be passed to the WhatsApp template preview/send tools.

get_conversations

Fetch the influencer's recent Instagram posts via Meta Graph API. influencer_id from auth when available; from param when admin.

get_instagram_posts

Fetch the influencer's Instagram profile via Meta Graph API. influencer_id from auth when available; from param when admin.

get_instagram_profile

Fetch a specific platform knowledge document by slug. Use list_knowledge first to discover available slugs.

get_knowledge

Return the current authenticated context: influencer_id (the one active for this request), user_id, scope (single-influencer | multi-influencer | admin), available_influencer_ids (selectable via X-Influencer-Id when the token carries a user_id; multi-influencer + admin tokens), and influencers (map of influencer_id → Instagram handle — identify a creator by handle but pass the influencer_id to tools). 'scope' is the selection mode, NOT a DB role, and does not limit which tools you can call. Same shape as GET /api/v1/me.

get_me

Returns managed files (e.g. changelog.md) from peer influencers that share the same use_case or vertical as the requesting influencer. influencer_id from auth when available; from param when admin. At least one of use_case or vertical must be provided. Returns { peers: [...], total }.

get_peer_managed_files

Fetch one playbook, template, or worked-example SDK by an `id` from get_playbook_index. For sample SDKs, call with no `section` to get the file manifest, then pass `section` to select a file (e.g. system, examples, objections, keywords, meta). Large docs paginate: when has_more is true, call again with the returned next_cursor.

get_playbook_doc

Call this FIRST before creating, iterating, analyzing, or answering any question about a Ninjo agent or the cortex SDK. Returns the catalog of operating manual, knowledge base, prompt-architecture templates, and worked-example SDKs; fetch the relevant ones with get_playbook_doc before drafting. A Ninjo agent is a SYSTEM (system prompt + the 8 v5Config fields + triggers + automation), not just a prompt — the playbook is how you build the whole system instead of a bare prompt.

get_playbook_index

Fetch self-serve onboarding data from MongoDB for an influencer. Returns data from four collections: - influencer_bio: IG profile processed by GPT (bio, audience, content formats, engagement patterns) - instagram_post: Posts with metrics and video transcriptions - instagram_conversation: DM conversations with followers - creator_input: Self-serve onboarding form (program details, lead magnets, style, use case) Missing sources are listed in missing_sources — expected for incomplete onboarding. Returns { influencer_id, sections: [{ source, count?, data }], missing_sources: string[] }.

get_self_serve_data

Get message history for a Cortex thread, ordered chronologically. Supports cursor-based pagination via the `before` parameter (ISO timestamp). Returns { messages: [{ id, role, content, created_at }] }.

get_thread_messages

Get the negative config (temporary block) of a trigger. When enabled and now < expires_at, the trigger is suppressed even if it would otherwise match. Returns { negative_config } which is null if none is set. trigger_type: keywords | all-messages | comments | ads (outgoing-messages and instagram-story are not supported).

get_trigger_negative_config

Get workflow activity snapshot (fires/evaluations) for the last N days. Returns { days, since, activity }.

get_workflow_activity

List every messaging channel a Ninjo agent answers, from BOTH sources, in one unified view. Returns { channels, count }; each channel carries source: "direct" (a Meta account — Instagram/WhatsApp — connected directly in Ninjo) or "crm" (a CRM sync connection — GoHighLevel, Kommo, HubSpot, Airtable — that RELAYS its messages to this agent). Use this to tell whether an agent is a free Meta agent or is dedicated to a CRM channel: a source:"crm" channel means the agent is NOT connected to Instagram directly — it answers the messages that arrive from GHL/Kommo through that channel. `channel_type` is the account type (direct) or the CRM provider (crm); `connected` is the single 'is this channel live' flag (direct: the Meta token is valid; crm: the connection is enabled and not disconnected). Metadata only — no access tokens or webhook secrets are returned.

list_agent_channels

List all tools/skills assigned to a Ninjo agent, including their enabled status, settings, and prompt.

list_agent_tools

List all agents belonging to the authenticated influencer. Returns { agents: AgentRow[], count: number }. Useful to resolve an agent_id when only the influencer identity is known.

list_agents

List the influencer's CRM sync connections (GoHighLevel, Kommo, HubSpot, Airtable). This is the ROOT of CRM discovery — it returns the sync_connection_id you pass to CRM property actions and to list_crm_pipelines / list_crm_fields. Unlike list_agent_channels (which shows only connections routed to a given agent), this shows ALL of the influencer's connections. Returns { connections, count }. Metadata only — no tokens or webhook secrets.

list_crm_connections

List a CRM connection's custom fields, fetched LIVE from the CRM. `entity` picks which object's fields — 'contact' or 'opportunity' — because CRM fields hang off a specific object. Each field's `id` is the crm_external_field_id you pass to a CRM_FIELD_UPDATE property action. Returns { fields, count }.

list_crm_fields

List the CRM pipelines synced for an influencer (optionally narrowed to one sync_connection_id). Use this to find the pipeline that holds the stage you want for a CRM_STAGE_TRANSITION property action. Pipelines come from the local synced mirror — if a connection has never synced they come back empty. Returns { pipelines, count }.

list_crm_pipelines

List the stages of a CRM pipeline (from list_crm_pipelines). Each stage's `id` is the crm_target_stage_id / crm_stage_id you pass to a CRM_STAGE_TRANSITION or CRM_PUSH_CONTACT property action. Stages come from the local synced mirror. Returns { stages, count }.

list_crm_stages

List connected Meta sub-accounts linked to a Ninjo agent. Returns { accounts, count }. Metadata only — no access tokens or secrets are returned.

list_connected_accounts